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1.  Introduction  and  Executive  Summary 

1.1  The  Promise  of  Finite  Element  Analysis 

The  finite  element  method  has  become  a  standard  for  design  analysis  of  aerospace 
structures.  It  is  an  irreplaceable  tool  for  all  aerospace  organizations,  and  for  the 
Air  Force  itself.  While  emphasis  has  shifted  somewhat  toward  commercial  software 
packages,  most  aerospace  firms  also  devote  significant  resources  to  in-house  finite 
element  software  development,  evaluation,  and  training.  Finite  element  analysis 
promises  faster  and  more  accurate  analysis,  more  efficient  designs,  and  less  depen¬ 
dence  on  costly  and  time-consuming  tests. 


1.2  The  Promise  Unfulfilled 

The  prevalence  of  finite  element  analysis  in  many  industries  is  testimony  to  its 
effectiveness.  Yet  in  some  ways  the  promise  of  the  method  remains  unfulfilled. 
Considerable  resources  are  devoted  to  finite  element  models,  and  the  return  on  these 
resources  is  not  what  it  should  be.  Many  models  die  a  premature  death  because 
they  were  not  adequately  documented,  verified,  publicized,  or  made  available  to 
organizations  that  could  have  made  use  of  them. 

Within  the  Air  Force,  this  problem  was  perceived  by  Dr.  V.  B.  Venkayya, 
Dr.  James  Olsen,  and  others  in  the  Structures  Division  of  the  Flight  Dynamics 
Laboratory  who  have  been  leaders  in  developing  methods  of  structural  analysis  and 
optimization  for  many  years.  Briefly,  the  problem  is  that  the  Air  Force  is  get¬ 
ting  nowhere  near  full  value  for  the  finite  element  models  that  are  developed  either 
directly  or  by  contractors.  Generally  speaking,  contractors  are  not  required  to 
deliver  the  models  they  develop  as  a  part  of  their  structural  design  analysis  work. 
There  are  many  circumstances  in  which  the  Air  Force  could  benefit  from  having 
these  models  after  the  aircraft  have  been  put  into  service.  When  such  circumstances 
arise,  Air  Force  personnel  have  no  good  choices.  They  either  develop  models  them¬ 
selves  (labor-intensive),  pay  a  contractor  to  develop  a  model  (expensive  and  difficult 
to  fund),  or  do  without  (losing  valuable  opportunities). 

The  idea  behind  this  SBIR  program  is  that  these  problems  might  be  remedied 
by  establishment  of  a  centralized  operation  dedicated  to  identifying,  collecting,  doc¬ 
umenting,  verifying,  storing,  modifying,  and  disseminating  finite  element  models  of 
Air  Force  aircraft.  In  addition,  a  specification  is  proposed  that  could  be  used  for 
future  procurement  programs  so  that  contractors  were  required  to  deliver  models 
to  the  Air  Force.  The  specification  would  primarily  address  documentation  and 
format  requirements. 
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1.3  Goals 

The  Phase  I  feasibility  study  was  intended  to  do  the  following: 

1.  Evaluate  current  practices  in  finite  element  analysis  among  selected  Air  Force 
organizations. 

2.  Outline  a  military  standard  that  could  eventually  be  used  to  specify  require¬ 
ments  for  delivery  of  finite  element  models  by  aircraft  development  contractors 
to  the  Air  Force. 

3.  Propose  a  plan  of  operation  for  an  Air  Force  center  where  models  would  be 
collected,  documented,  verified,  modified,  stored,  retrieved,  and  distributed, 
with  emphasis  on  potential  cost  savings. 

4.  Investigate  supporting  software  that  could  be  used  in  the  operation  of  this 
Center. 

Phase  II  will  form  a  pilot  operation  with  attention  focused  on  models  of  a  paxticulax 
aircraft.  Following  Phase  II,  full  operation  of  a  Center  is  contemplated. 


1.4  Findings 

The  findings  of  this  study  may  be  summarized  briefly  as  follows: 

1.4.1  Survey  Confirms  FDL  Suspicions 

The  Air  Force  is  not  getting  full  benefit  from  the  finite  element  models  of  aircraft 
structures  that  are  developed  by  contractors.  The  perceptions  of  FDL  engineers 
and  others  that  this  is  so  are  supported  by  the  survey  reported  in  Section  3  and 
by  the  authors’  personal  experience.  This  is  partly  a  management  problem  and 
partly  a  technical  problem.  That  is,  there  are  few  if  any  organized  procedures 
for  acquiring,  documenting,  modifying,  and  distributing  these  models.  This  report 
shows  that  these  problems  Eire  costing  the  Air  Force  a  lot  of  money  and  many  lost 
opportunities. 

1.4.2  Lack  of  Model  Delivery  Requirements:  the  Consequences 

Contractors  Eire  not  currently  required  to  deliver  the  finite  element  models  they 
develop  while  designing  aircraft.  Our  survey  showed  several  cEises  where  Air  Force 
organizations  needed  models  that  perhaps  should  have  been  delivered  when  the 
Eurcraft  were  procured.  In  these  csises  they  either  paid  for  another  model  to  be 
created,  or  did  without.  There  have  probably  been  many  cases  where  Air  Force 
organizations  recognized  a  need  for  a  model  but  immediately  dismissed  the  idea, 
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believing  that  the  obstacles  to  finding  or  creating  the  model  they  needed  were  too 
great. 

1.4.3  Mil-Standard  Needed 

It  will  not  be  sufficient  to  simply  insert  a  new  CDRL  item  in  future  contracts  to 
require  delivery  of  models.  A  standard  is  necessary  to  specify  the  format  of  the 
data,  and  the  form  and  content  of  supporting  documentation.  An  outline  for  such 
as  standard  is  presented  in  Section  6  of  this  report. 

1.4.4  Documentation  is  Crucial 

The  importance  of  documentation  supporting  finite  element  models  is  difficult  to 
overstate,  no  matter  where  the  models  come  from.  Undocumented  raw  data  can 
be  very  difficult  (even  dangerous)  to  use.  Documentation  is  especially  important 
when  several  variations  of  a  basic  model  exist,  as  shown  in  the  case  study  described 
in  Section  4.  Another  case  study,  showing  well-documented  models,  appears  in 
Section  5. 


1.5  Recommendations 

The  recommendations  presented  in  this  report  are  based  partly  on  the  survey  results 
and  partly  on  the  personal  experience  of  three  of  the  engineers  who  worked  on  it. 
This  experience  amounts  to  about  forty  years  among  the  three  of  them  doing  finite 
element  analysis.  The  recommendations  are  as  follows: 

1.5.1  Air  Force  Aircraft  Model  Center  Proposed 

A  centralized  activity  is  proposed  for  supporting  finite  element  models  of  Air  Force 
aircraft.  This  activity  is  tentatively  called  the  Air  Force  Aircraft  Model  Center. 
The  Center  would  be  responsible  for  acquiring,  validating,  documenting,  modifying, 
distributing,  and  publicizing  finite  element  models  of  Air  Force  structures.  The 
following  payoffs  are  envisioned: 

1.  Costs  incurred  in  acquiring  or  developing  models  would  be  avoided  in  cases 
where  the  Center  can  supply  an  existing  model  to  an  Air  Force  organization. 
Costs  are  discussed  in  Sections  3  and  4  and  in  the  Appendix. 

2.  Dramatic  benefits  can  be  foreseen  in  situations  where  a  change  in  an  aircraft’s 
structure,  loads,  or  mission  requires  quick  evaluation  of  stresses  or  other  struc¬ 
tural  responses.  If  no  model  is  available,  quick  response  is  impossible.  If  the 
Center  can  provide  a  well-documented  model,  ready  for  use  (or  nearly  so),  the 
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cost  savings  and  additional  benefits  could  propagate  widely  through  the  Air 
Force. 

3.  Researchers  and  developers  will  have  at  their  disposal  a  library  of  models  that 
they  can  use  to  validate  new  technology  such  as  optimization  or  multidisci¬ 
plinary  analysis. 

1.5.2  Mil-Standard  Outlined 

An  outline  of  a  proposed  Mil-Standard  for  finite  element  models  is  developed  in 
Section  6.  Its  aim  is  to  insure  that  developers  of  future  aircraft  systems  will  deliver 
models  to  the  Air  Force  according  to  certain  standards.  The  standards  address 
matters  such  as  documentation,  verification,  and  format. 

1.5.3  Database  Software  Identified 

A  specific  database  solution  has  been  identified  that  addresses  the  problems  of 
identification,  storage,  and  documentation  of  models.  It  also  provides  automatic 
tracking  of  updates  and  variations,  along  with  documentation  keyed  to  the  actual 
bulk  data.  The  software  will  provide  menu-driven  search  and  retrieval  functions 
tailored  to  the  needs  of  structural  analysts.  The  software  is  spelled  out  in  detail  in 
Section  7. 

1.5.4  Phase  II  Plan  Developed,  Permanent  Operation  Foreseen 

A  plan  has  been  developed  for  Phase  II  in  which  the  ideas  identified  in  Phase  I  will 
be  exercised  on  live  data.  This  plan  is  discussed  in  Section  10,  with  more  detail 
presented  in  the  actual  Phase  II  proposal.  The  goal  of  Phase  II  is  to  accumulate 
the  experience,  software,  etc.,  necessary  for  operating  the  envisioned  Center.  Center 
operation  is  discussed  in  Section  11. 
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2.  Statement  of  the  Problem 

With  each  new  Air  Force  aircraft  system  that  has  been  developed,  finite  element 
analysis  (FEA)  has  played  a  greater  role  in  the  structural  design  analysis  pro¬ 
cess.  Older  aircraft  such  as  the  B-52  that  were  designed  entirely  by  hand  have  also 
been  the  subject  of  finite  element  analysis  in  recent  years.  Certainly  FEA  is  now 
irreplaceable  in  aircraft  structural  design  and  analysis.  However,  as  Drs.  Venkayya 
and  Olsen  point  out  in  their  recent  paper  (Ref.  [3]),  the  Air  Force  is  not  getting  full 
value  for  the  resources  that  are  spent  either  directly  or  by  contractors  on  FEA. 

Before  defining  the  problem  in  more  detail,  it  will  be  useful  to  review  the  evolu¬ 
tion  of  finite  element  analysis,  and  to  summarize  the  current  state  of  affairs  in  this 
field. 


2.1  Evolution  of  Finite  Element  Analysis 

The  finite  element  method  evolved  in  parallel  with  the  rise  of  digital  computers. 
Because  of  intensive  matrix  computations,  a  computer  is  necessary  for  even  the 
simplest  models.  Twenty  years  ago,  FEA  was  much  different  than  it  is  today. 
NASTRAN  had  not  yet  appeared,  and  most  organizations  supported  their  own 
in-house  codes.  Card  decks  were  standard,  and  a  big  model  had  a  thousand  degrees 
of  freedom.  Pen  plotters  were  the  state  of  the  art  in  graphics. 

At  first,  attention  was  naturally  focused  on  basic  methods:  issues  like  ele¬ 
ment  formulations  and  equation  solution  methods.  Later,  software  reliability  and 
expanded  problem  sizes  were  addressed.  In  recent  years,  considerable  effort  has 
been  expended  on  graphical  pre-  and  post-processors.  Perhaps  the  present  effort 
will  turn  out  to  be  part  of  another  shift  in  focus  in  the  industry,  this  time  toward 
protecting  investments  in  models  by  organized  efforts  to  verify,  document,  preserve, 
and  disseminate  these  models. 


2.2  Costs  of  Finite  Element  Analysis 

The  costs  of  developing  a  finite  element  model  can  be  staggering.  One  of  the 
engineers  whom  we  contacted  in  our  survey  (Section  A.l)  quoted  a  cost  of  $500,000 
for  development  of  a  model  they  wanted.  While  this  was  an  off-the-cuff  remark, 
it  probably  reflects  the  order  of  magnitude  of  the  costs  that  can  be  incurred  in 
modeling. 

There  are  three  major  components  of  the  overall  cost: 

1.  Computer  hardware. 

2.  Computer  software. 
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3.  Engineering  manpower. 

It  is  common  knowledge  that  the  hardware  cost  of  performing  a  unit  of  computa¬ 
tion  has  dropped  spectacularly  in  recent  years.  But  demand  has  kept  pace  with 
the  falling  unit  costs  so  that  hardware  expenditures  have  fallen  only  slightly  in 
absolute  terms;  perhaps  more  in  percentage  terms.  However,  these  costs  can  still 
be  substantial.  In  large  organizations,  finite  element  analysis  tasks  can  consume 
much  of  the  power  of  a  multi-million  dollar  supercomputer. 

Engineering  software  effectiveness  has  increased  more  slowly,  but  again  demand 
has  more  than  offset  gains  here. 

Engineering  manpower  productivity  has  increased  most  slowly.  Most  of  the  man¬ 
power  productivity  gains  have  come  about  with  the  introduction  of  graphics  pre- 
and  post-processing  software.  In  both  absolute  and  percentage  terms,  manpower 
costs  in  FEA  have  risen  substantially. 

Thus  manpower  is  certainly  the  most  important  consideration  in  FEA  costs. 
Two  keys  to  controlling  manpower  costs  are  (1)  to  be  sure  that  expensive  engineers 
are  working  on  the  right  problem,  and  (2)  that  they  are  not  duplicating  someone 
else’s  work.  This  is  where  dissemination  and  documentation  play  a  key  role.  Clearly, 
if  an  Air  Force  organization  can  acquire  the  right  model  rather  than  reinvent  it, 
considerable  time  and  funds  will  be  saved.  If  the  model  is  properly  documented, 
engineers  will  be  sure  of  what  they  are  working  on. 


2.3  Air  Force  Needs  for  Finite  Element  Models 

All  developers  of  Air  Force  aircraft  use  finite  element  analysis  in  the  structural 
design  process.  Considerable  resources  (computer  hardware  and  software  costs; 
engineering  manpower)  are  devoted  to  the  development,  verification,  and  use  of 
these  models.  These  resources  are  ail  provided,  at  least  indirectly,  by  the  govern¬ 
ment,  and  so  it  would  seem  that  these  models  ought  to  belong  to  the  government. 
However,  contractors  only  deliver  what  their  contract  requires  them  to  deliver. 

There  are  many  reasons  why  Air  Force  organizations  such  as  ASD,  AFLC,  and 
AFWAL  might  need  such  models,  such  as 

•  Providing  support  for  repair  and  maintenance  operations, 

•  Investigating  new  versions  of  aircraft  (e.g.,  F15A  —  F15E), 

e  Investigating  modifications  to  existing  aircraft  (new  weapons  systems,  perfor¬ 
mance  enhancements,  etc.), 

®  Validation  of  contractors’  analyses,  and 
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•  Provision  of  realistic  test  problems  for  validation  of  new  technology.  New 
capabilities  added  to  the  ASTROS  software,  for  example,  need  to  be  evaluated 
on  realistic  problems.  Models  of  existing  systems  are  ideal  for  this  purpose. 

Since  there  has  been  no  requirement  for  delivery  of  models  in  past  system  devel¬ 
opments,  models  have  been  obtained  under  less  than  satisfactory  conditions,  if  at 
all: 

•  Models  have  been  acquired  from  the  developers  through  informal  requests, 
usually  with  little  or  no  supporting  documentation, 

•  Models  are  sometimes  purchased  (twice,  in  effect)  from  the  original  system 
developers, 

•  Contracts  are  sometimes  let  to  third  parties  to  create  new  models. 

The  Air  Force  does  not  have  the  manpower  to  devote  to  creating  complex  models, 
so  until  now,  these  three  approaches  have  been  the  only  means  of  obtaining  the 
required  models. 

Getting  contractors  to  deliver  models  means  more  than  just  another  item  added 
to  a  CDRL.  It  will  be  necessary  to  provide  specific  requirements  regarding  docu¬ 
mentation,  verification,  and  data  formats.  This  subject  is  addressed  in  some  detail 
in  Section  6.  This  specification  expands  on  the  ideas  presented  by  Dr.  Venkayya  in 
his  DID  (Ref.  [2])  and  in  his  conference  paper  (Ref.  [3]). 


2.4  Need  for  Documentation 

The  authors  know  from  personal  experience  the  importance  of  documentation  of 
finite  element  models.  This  becomes  dramatically  apparent  to  an  analyst  who  is 
given  an  undocumented  model  and  asked  to  make  modifications.  In  the  worst  case, 
without  even  any  comments  m  the  bulk  data,  the  analyst  must  begin  a  laborious 
process  of  plotting  and  running  the  model.  Plots  are  necessary  to  find  out  node 
point  and  element  locations,  and  to  relate  element  properties  and  material  types  to 
specific  areas  of  the  structure.  Test  runs  must  be  made  to  validate  the  model  for 
statics  and  dynamics. 

Documentation  issues  are  addressed  in  Section  6,  which  outlines  requirements 
for  delivery  and  documentation  of  models,  and  in  Section  7  which  proposes  database 
software  that  would  not  only  preserve  existing  documentation  and  make  it  accessi¬ 
ble,  but  also  encourage  users  to  provide  additional  documentation. 
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3.  A  SURVEY  OF  FINITE  ELEMENT  USERS 


3.  A  Survey  of  Finite  Element  Users 

Six  Air  Force  organizations  and  one  NASA  organization  involved  in  structural  anal¬ 
ysis  were  surveyed  during  the  course  of  this  effort.  Some  of  them  were  interviewed 
in  person,  others  by  telephone.  The  main  purpose  of  the  surveys  was  to  gauge  the 
need  for  a  Center  as  contemplated  in  this  SBIR.  The  respondents  were  asked  about 
their  use  of  finite  element  models,  particularly  how  they  acquired  them,  verified 
them,  and  used  them.  Another  purpose  was  to  ask  them  if  they  thought  that  a 
Center  such  as  we  propose  would  be  useful  to  them. 

The  following  organizations  were  surveyed:  ASD/ENFS  (WPAFB),  Egiin  AFB, 
4950th  Test  Wing  (WPAFB),  Warner- Robbins  ALC,  Hill  AFB,  Sacramento  ALC 
(McClellan  AFB),  and  NASA/Dryden.  Transcripts  of  each  interview  appear  in  the 
Appendix. 

All  six  Air  Force  organizations  are  definitely  mvolved  in  struct  ural  analysis  and 
would  be  potential  users  of  or  contributors  to  the  proposed  Center.  While  some 
are  more  active  than  others  in  creating  or  using  models,  all  are  heavily  dependent 
on  contractors  to  supply  them  with  models.  More  to  the  point,  they  nearly  always 
depend  on  the  contractor’s  assurance  that  the  model  is  valid.  Clearly,  all  these 
organizations  would  benefit  from  better  procedures  for  delivering,  documenting, 
and  verifying  models. 

All  the  organizations  surveyed  have  access  to  DEC  VAX  computers.  Most  of 
them  also  access  Cray  or  Cyber  mainframes. 

All  six  organizations  use  NASTRAN,  although  Sac  ALC  prefers  to  use  GIFTS 
whenever  possible.  The  two  organizations  at  WPAFB  (ASD  and  4950th)  use 
COSMIC  NASTRAN  (although  4950th  also  has  access  to  MSC/NASTRAN  through 
a  commercial  computing  network).  The  other  four  use  MSC/NASTRAN  exclu¬ 
sively.  This  situation  generally  reflects  the  predominance  of  NASTRAN  in  industry. 
There  is  a  wide  variation  in  pre-  and  post-processing  software,  however.  Among  the 
six  organizations,  two  use  PATRAN,  one  SUPERTAB,  one  GIFTS,  one  is  getting 
NAVGRAF,  and  one  did  not  report  any  graphics  software. 

Following  were  some  of  the  more  interesting  responses,  paraphrased: 

“When  you  have  to  go  to  the  contractor  for  a  model,  it’s  going  to  take 
a  year  or  more,  so  if  something  has  to  be  done  in  a  timely  manner,  it 
just  doesn’t  get  done.” 

“Only  contractors  understand  models,  to  any  real  degree.” 

“We  spent  $50,000  to  obtain  a  model.  The  model  was  actually  ‘free’; 
the  documentation  cost  $50,000.  Creating  the  model  would  have  cost 
$500,000.” 
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“How  do  we  validate  models?  As  best  we  can!” 

“Use  of  COSMIC  NASTRAN  instead  of  MSC/NASTRAN  would  be  a 
‘kiss  of  death’  for  the  Center.” 

Responses  to  the  idea  of  a  Model  Center  varied  widely.  Hill  was  “very  recep¬ 
tive,”  saying  the  Center  could  help  “a  lot.”  ASD  and  the  4950th  favored  it,  ASD 
implying  that  the  Center  might  make  it  possible  to  undertake  some  structural  anal¬ 
ysis  projects  that  would  otherwise  be  impossible.  Warner-Robbins  had  moderate 
interest  with  reservations,  Sac  ALC  was  negative,  and  Eglin  had  no  opinion. 

We  do  not  claim  that  this  semi-formal  survey  of  seven  organizations  is  compre¬ 
hensive.  We  do  believe  that  it  supports  the  conclusion  that  there  is  a  need  for  and  a 
cautious  interest  in  a  Model  Center.  Reading  between  the  lines,  we  would  say  that 
most  of  the  organizations  are  willing  to  be  shown  that  the  Center  would  benefit 
them.  Thus,  the  manner  in  which  the  Center  is  presented  to  potential  user  organi¬ 
zations  will  be  crucial.  People  become  comfortable  in  their  ways  of  doing  their  job, 
and  Eire  often  resentful  of  outsiders  whom  they  perceive  as  intruding,  interfering,  or 
threatening  their  position.  This  what  we  inferred  from  the  response  received  from 
Sac  ALC.  Thus  it  will  be  very  important  that  results  can  be  shown  at  the  end  of 
Phase  II  which  can  be  shown  to  benefit  other  Air  Force  organizations.  That  is,  we 
should  be  able  to  go  into  one  of  these  organizations  and  say,  “Here’s  what  we’ve 
accomplished  in  our  trial  operation  of  the  Model  Center,  and  here’s  how  it  could 
benefit  your  organization  in  the  future.”  It  will  be  important  to  address  this  pre¬ 
sentation  to  the  proper  levels  of  management,  not  just  the  workers  who  deal  with 
models.  This  is  because  the  benefits  of  the  Center  need  to  be  understood  in  terms 
of  organizational  mission  performance  and  costs. 
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4.  F-16  Case  Study:  Consequences  of  Poor 

Documentation 

Some  of  the  difficulties  and  frustrations  experienced  in  working  with  a  model 
obtained  with  little  or  no  documentation  can  be  illustrated  with  the  following  case 
study  which  was  performed  for  FDL. 


4.1  Evaluating  the  Finite  Element  Models 

A  finite  element  analysis  was  requested,  to  quantify  and  evaluate  the  effects  of  real 
damage  caused  by  live  firings  on  an  F-16  wing.  Two  finite  element  models  were 
located  and  obtained.  One  model  was  an  MSC/NASTRAN  model  freshly  obtained 
from  General  Dynamics.  This  model  was  very  extensive,  containing  over  7,000  grid 
points  and  an  immense  amount  of  structural,  detail.  The  other  model  had  been 
around  the  Flight  Dynamics  Laboratory  for  several  years,  so  long  that  its  origin 
had  been  forgotten.  This  model  contained  around  400  grid  points  and  over  1,000 
elements.  Plots  of  the  two  models  may  be  seen  in  Figures  1  and  2.  Note  that 
the  coarse  model  shown  includes  some  elements  within  the  fuselage,  presumably  for 
modeling  the  wing  root  stiffness. 

Neither  model  had  any  documentation,  so  it  was  necessary  to  run  the  models, 
obtain  plots,  and  study  the  results  in  order  to  gain  an  understanding  of  each  model, 
its  structure,  constraints,  and  materials.  The  larger  model  had  to  be  converted  to 
COSMIC  NASTRAN  and  then  debugged  before  it  could  be  run.  All  this  prelimi¬ 
nary  work  used  up  considerable  engineering  manpower  and  computer  time  without 
producing  any  directly  applicable  results. 

It  would  have  been  desirable  to  use  the  more  detailed  model,  but  the  required 
time  and  manpower  would  have  been  excessive.  This  was  partly  because  so  much  of 
the  budget  was  consumed  in  preliminary  activities.  It  therefore  seemed  necessary 
to  use  the  coarse  model.  From  the  preliminary  work,  the  coarse  model  appeared 
acceptable,  since  it  seemed  to  represent  a  fully  configured  wing.  But  before  it  could 
be  used  with  confidence,  it  had  to  be  validated  in  some  way. 


4.2  Verifying  the  Coarse  Model 

When  the  same  static  load  was  applied  to  each  model  the  predicted  deflections 
were  very  similar.  This  gave  evidence  that  the  two  models  had  essentially  the 
same  bending  stiffness.  However,  when  computed  deflections  were  compared  to 
measured  deflections  obtained  from  a  test  having  ostensibly  the  same  loads,  the 
results  disagreed  by  over  100  per  cent.  This  was  found  to  be  due  to  flexibility  in  the 
test  fixture  jig  at  the  wing  root  It  should  have  been  possible  to  introduce  flexibility 
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Figure  1.  F16  coarse  model 
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Figure  2,  F16  fine  model 


4.3  Cataioging  the  Models 


13 


into  the  root  area  of  the  wing  model  so  that  predicted  deflections  could  be  made  to 
match  the  test  results.  Again,  time  and  manpower  constraints  did  not  allow  this. 
It  appeared  that  a  comparison  of  dynamic  results  would  be  easier,  and  this  was 
undertaken  instead. 

First,  the  fully  configured  FDL  finite  element  model  was  compared  to  the  results 
of  an  FDL  ground  vibration  test  on  a  similarly  configured  wing  on  an  actual  aircraft. 
The  first  two  natural  modes  matched  quite  well. 

The  next  step  was  to  compare  the  model  to  vibration  tests  of  the  test  wing,  since 
these  tests  would  be  conducted  several  times  between  firings  in  order  to  evaluate 
changes  in  the  dynamics  of  the  wing.  Since  the  test  wing  was  stripped  of  all  external 
structure,  it  was  necessary  to  remove  all  items  such  as  the  front  and  rear  flaps, 
missiles,  and  pylons  from  the  model.  This  was  a  time-cons  tuning  task  due  to  the 
lack  of  documentation.  The  predicted  weight  was  still  about  200  pounds  greater 
than  the  measured  weight,  so  it  was  necessary  to  remove  a  percentage  of  the  non- 
structural  mass  included  in  the  model.  After  the  weight  had  been  adjusted  to 
within  a  few  pounds,  the  first  four  natural  modes  predicted  by  the  model  matched 
the  vibration  tests  within  a  few  per  cent. 

This  correlation  was  considered  close  enough  to  proceed  with  the  damage  study. 
Each  damage  case  was  modeled  and  static  and  dynamic  characteristics  were  tab¬ 
ulated  before  and  after  each  shot  in  order  to  assess  residual  strength  degradation 
due  to  the  damage.  Ten  damage  cases  were  analyzed  for  the  study.  Since  the  test 
wing  was  repaired  after  each  test,  these  repairs  also  had  to  be  modeled. 


4.3  Cataloging  the  Models 

Ten  damage  cases  with  two  models  each  resulted  in  twenty  configurations,  along 
with  four  configurations  of  the  undamaged  model.  (Three  test  wings  were  used  for 
the  tests,  each  varying  slightly  in  configuration  and  weight,  depending  on  the  struc¬ 
ture  removed.)  A  dynamic  and  a  static  analysis  was  made  with  each  model.  As  a 
result,  there  were  48  NASTRAN  decks  in  use.  The  differences  between  decks  varied 
from  a  few  dozen  cards  to  a  few  hundred.  Bookkeeping  became  very  important  in 
keeping  track  of  each  model  and  in  preventing  errors  from  propagating. 

For  similar  analyses  done  in  the  early  1970’s,  the  CDC  UPDATE  utility  was 
used  (see  Section  7).  The  original  model  was  kept  on  permanent  file,  and  a  separate 
update  deck  in  punched  card  format  was  kept  for  each  case.  These  decks  could  be 
marked  and  written  on  in  order  to  keep  them  straight. 

For  the  F-16  study,  complete  decks  were  kept  on  permanent  files.  The  CDC 
permanent  file  system  allows  only  seven  characters  for  file  names,  so  a  shorthand 
system  had  to  be  devised  and  a  manual  log  book  kept.  After  models  were  no 
longer  actively  needed  they  were  archived  to  the  Central  File  System  (CFS).  The 
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CFS  allows  file  names  up  to  about  thirty  characters  long,  so  that  descriptive  titles 
could  be  used.  The  approach  used  here  was  superior  to  the  old  UPDATE  method 
because  the  engineer  could  use  a  screen  editor  instead  of  the  cumbersome  line- 
oriented  directives  required  by  UPDATE.  However,  one  advantage  of  UPDATE 
was  lost.  When  one  model  is  derived  from  another,  the  UPDATE  method  provides 
an  explicit  indication  (in  the  form  of  correction  sets)  of  the  differences  between  the 
two  models.  No  such  direct  comparison  is  possible  when  separate  files  are  kept  for 
all  models. 

Comment  cards  were  inserted  in  the  various  decks  to  describe  the  changes  that 
were  made. 


4.4  How  a  Database  might  have  Helped 

If  the  database  scheme  proposed  in  Section  7  had  been  available  when  this  study  was 
done,  it  could  have  helped  in  three  ways.  It  could  have  provided  a  better  starting 
point  for  the  effort,  smoother  procedures  during  the  effort,  and  an  end  product  that 
would  be  more  accessible  to  future  users. 

If  a  well-documented  and  verified  model  had  existed  prior  to  this  effort,  a  savings 
of  at  least  25%  of  the  labor  would  have  been  possible,  according  to  the  engineer 
who  did  the  work.  The  work  would  have  been  easier  because  it  would  not  have 
been  necessary  to  track  models  and  file  names  manually.  The  database  scheme 
proposed  in  Section  7  would  have  provided  automated  tracking  of  models,  with 
tracing  of  the  derivation  of  one  model  from  another.  It  would  have  provided  both 
the  convenience  of  a  screen  editor  and  the  traceability  of  UPDATE.  It  would  have 
encouraged  the  engineer  to  provide  adequate  documentation  at  every  step,  while 
providing  reversibility  of  all  changes.  Finally,  although  the  CFS  works  well  when  it 
is  up,  it  goes  down  frequently  (or  did  when  the  study  was  done).  This  aggravation 
would  have  been  avoided  with  a  database  implemented  on  a  VAX.  In  summary, 
while  the  job  got  done,  the  engineer  likened  it  to  using  a  hand  saw  in  comparison 
to  a  power  saw. 

The  same  engineer  has  stated  that  he  would  be  able  to  find  the  files  and  notes 
and  continue  the  study  with  relatively  little  difficulty  if  he  were  called  on  to  do  so. 
He  also  stated  that  it  would  be  virtually  impossible  for  anyone  else  to  do  so  without 
his  assistance. 
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5.  B-l  and  F-15E  Case  Studies:  Well- documented 
Models 

In  this  section,  two  large  finite  element  aircraft  analysis  programs  are  reviewed. 
They  were  selected  because  they  provide  examples  of  well-documented  models. 


5.1  B-l  Model  for  an  Airloads  Research  Study 

Rockwell  International  developed  a  model  of  the  B-l  aircraft  number  two 
(A/C-2)  for  NASA/Dryden  Research  Facility  in  the  early  1980’s  (Ref.  [4]).  The 
purpose  of  the  study  was  to  utilize  flight  data  acquired  during  B-l  flights  and  per¬ 
form  analyses  of  these  data  beyond  the  scope  of  Air  Force  requirements.  Specifically, 
the  structural  model  was  to  be  used  to  calculate  influence  coefficients  which  would 
then  be  passed  to  the  NASA  aerodynamics  code,  FLEXSTAB.  Although  detailed 
models  were  available  at  Rockwell,  it  was  decided  to  develop  coarse  models  so  that 
the  aerodynamic  studies  could  be  executed  efficiently.  Seven  substructures  were 
modeled  (wing,  forward  fuselage,  aft  fuselage,  horizontal  and  vertical  stabilizers, 
fairings,  and  nacelle)  with  a  total  of  about  3520  grid  points.  The  report  appeared 
in  five  volumes  (NASTRAN  model  plans;  horizontal  stabilizer,  vertical  stabilizer, 
and  nacelle  structures;  wing  structure;  fuselage  structure;  and  fairing  structure) . 

This  report  is  cited  because  it  represents  a  thoroughly  documented  finite  ele¬ 
ment  model.  The  introduction  begins  by  explaining  the  reason  for  the  model,  i.e., 
providing  flexibility  matrices  of  sufficient  complexity  for  use  with  FLEXSTAB,  an 
aeroelastic  code.  This  is  followed  by  brief  physical  descriptions  of  the  aircraft  as  a 
whole,  and  each  component. 

There  is  an  explanation  of  the  DMAP  code  that  was  written  to  provide  the 
required  matrices  for  interfacing  with  FLEXSTAB.  Following  this  is  a  package  of 
engineering  drawings  that  were  used  in  developing  the  model. 

Separate  volumes  are  provided  for  each  substructure.  The  wing  volume,  volume 
III,  for  example,  begins  with  some  engineering  drawings  and  then  gives  an  expla¬ 
nation  of  the  NASTRAN  input,  consisting  of  several  pages  copied  from  the  User’s 
Manual.  This  would  probably  be  unnecessary  today  with  NASTRAN  having  be¬ 
come  so  well  known.  There  is  a  page  that  explains  the  numbering  scheme  that  was 
used  (e.g.,  grid  number  XX YY  lies  on  rib  XX  and  spar  YY).  Similar  conventions 
axe  given  for  element  numbers. 

Following  this  is  an  exhaustive  series  of  plots  generated  by  NASTRAN.  It 
appears  that  every  grid  point  and  every  element  is  labelled  in  at  least  one  plot. 
For  example,  see  Figures  3  through  6  which  show  all  grid  and  element  numbers  for 
the  outboard  wing  lug  area. 
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Figure  3.  Upper  outboard  wing  pivot  lug  grid  points 


5.1  B-l  Model  for  an  Airloads  Research  Study 
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NASTRAN  wing  model  ID 
Axial  elements: 

CONROD  -  XXXXCR 
Panel  elements: 

CQ.UAD2  -  20XXXXQ.2  (quadr i l atera I  plate) 
CTRIA2  -  21 XXXXT2  (triangular  plate) 
where  XXXX  *  lowest  adjacent  grid 
no.  when  available 


Y 


Figure  4.  Upper  outboard  wing  pivot  lug  elements 
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Figure  5.  Lower  outboard  wing  pivot  lug  grid  points 


5.1  B-l  Model  for  an  Airloads  Research  Study 
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NASTRAN  wing  model  ID 
Axial  elements 
CONROD  -  XXXXCR 
Panel  elements 

CQUAD2  -  20XXXXQ2  (quadrilateral  plate) 
CTRIAZ  -  21XXXXT2  (triangular  plate) 
where  XXXX  •  lowest  adjacent  grid 
no.  when  available 


Figure  6.  Lower  outboard  wing  pivot  lug  elements 
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5.  B-l  AND  F-15E  CASE  STUDIES:  WELL-DOCUMENTED  MODELS 


The  text  asserts  that  the  model  was  checked  for  continuity,  constraints,  etc., 
using  an  interactive  graphics  code.  Results  axe  presented  for  unit  loading  at  each  of 
a  number  of  selected  influence  coefficient  points.  Plots  show  selected  displacements 
plotted  versus  results  predicted  by  the  detailed  B-l  model.  Good  agreement  is 
shown. 

Finally,  a  sorted  bulk  data  echo  of  over  4000  cards  is  given. 

Thus,  the  report  presents  practically  all  the  information  that  would  be  needed 
by  an  analyst  assigned  to  pick  up  this  model  and  use  it.  Engineering  drawings 
axe  given,  complete  plots  axe  presented,  the  numbering  scheme  is  explained,  and 
evidence  of  verification  is  given.  The  only  category  not  covered  is  documentation 
of  loads.  There  were  no  loads  per  se,  smce  the  purpose  of  the  study  was  to  develop 
influence  coefficients. 

As  an  aside,  one  wonders  whether  the  project  would  be  undertaken  at  all  if  it 
were  proposed  today.  If  the  detailed  model  referenced  in  the  report  were  avail¬ 
able  from  Rockwell,  and  given  today’s  tradeoff  between  engineering  labor  costs  and 
computer  costs,  it  might  be  better  to  simply  run  with  the  complex  model.  Second, 
one  wonders  whether  any  contractor  other  than  Rockwell  could  have  done  the  job. 
This  would  depend  on  whether  the  detailed  model  (which  was  of  course  created  by 
Rockwell)  could  have  been  obtained  by  another  contractor,  and  if  so,  whether  it 
would  have  been  documented  adequately. 

5.2  F-15E  Model 

Another  contractor  report  is  cited  as  an  example  of  good  documentation  of  loading 
conditions.  This  is  the  stress  report  for  the  F15-E  aircraft,  Ref.  [5],  specifically, 
section  11.9.2,  loading  Conditions. 

The  section  on  loading  conditions  begins  with  a  discussion  of  factors  of  safety, 
ultimate  loads,  thermal  effects,  and  conservative  combinations  oi  engine  thrust 
loads,  flight  loads,  and  cockpit  pressures.  Crash  loads  and  pilot  apphed  loads  are 
also  considered.  The  computer  program  used  to  develop  load  distributions  is  refer¬ 
enced. 

Table  1  (copied  from  table  11.9.2-1  of  the  report)  shows  a  listing  of  load  con¬ 
ditions  that  were  selected  as  critical  for  the  forward  fuselage.  Each  line  of  the 
table  indicates  the  condition  number  used  in  NASTRAN,  the  engine  thrust  (max 
or  min),  Mach  number,  altitude,  a  brief  description  of  the  condition,  limit  load 
factors,  cockpit  pressure,  a  description  in  terms  of  the  the  effects  on  the  structure, 
and  an  indication  of  the  areas  that  axe  critical  for  the  particular  condition.  This 
last  item  would  be  especially  useful  for  someone  picking  up  the  model  for  the  first 
time,  intending  to  use  it  in  an  optimization  study,  for  example. 
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Table  1.  Forward  fuselage  design  loading  conditions 
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6.  Standards  for  Delivery  of  Finite  Element 
Models 

The  reasons  why  the  Air  Force  should  require  its  contractors  to  deliver  finite  ele¬ 
ment  models  developed  in  the  course  of  their  work  have  already  been  noted.  In  order 
to  enforce  this  requirement  on  developers  of  future  systems,  a  Mil-Standard  must 
eventually  be  developed.  This  section  presents  some  information  on  finite  element 
models,  pre-processors,  and  NASTRAN  as  a  standard.  This  background  informa¬ 
tion  leads  into  a  preliminary  outhne  of  a  Mil-Standard  directed  toward  delivery  of 
finite  element  models. 

6.1  Background  on  Finite  Element  Models  and  Their  Use 

We  begin  this  section  with  a  general  discussion  of  finite  element  modeling  as  back¬ 
ground  for  the  subsequent  discussion  of  delivery  requirements  for  finite  element 
models. 

In  finite  element  structural  analysis,  we  are  solving  some  kind  of  matrix  equation 
which  can  be  stated  in  a  general  way  as 

/(K(U,fl,u,),M,B,U(«),U(t),U(«),()  =  P(K,M,U, (,»,«)  (1) 

Here  we  denote  stiffness,  mass,  and  damping  matrices  by  K,  M,  and  B;  displace¬ 
ments  by  U,  loads  by  P,  time  by  t,  frequency  by  u>,  and  temperature  by  6 ,  showing 
that  stiffness  may  be  a  function  of  displacement,  temperature,  or  frequency,  and 
that  loads  may  be  functions  of  stiffness,  mass,  displacement,  time,  frequency,  or 
temperature.  Thus,  the  familiar  linear  static  analysis  would  be  just 


KU  =  P  (2) 

whereas  a  geometrically  nonlinear  transient  analysis  with  follower  forces  would  be 
written 

K(U)U  +  BU  +  MU  =  P(f,U)  (3) 

This  example  shows  that  nonlinearity  is  usually  introduced  implicitly  (i.e.,  K  and 
P  are  shown  as  functions  of  the  independent  variable  U).  This  leads  to  iterative 
solutions  of  the  equations. 

Based  on  this  general  formulation,  we  may  state  three  basic  questions  facing  the 
modeler: 

1.  What  equations  are  to  be  solved;  i.e.,  what  is  /?  Do  we  have  a  static  or 
dynamic  problem,  steady-state  or  transient,  linear  or  nonlinear? 


6.1  Background  on  Finite  Element  Models  and  Their  Use 
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2.  How  to  develop  K,  M,  and  B.  This  is  determined  by  the  layout  of  grids 
and  elements,  and  by  element  types.  These  questions  in  turn  axe  governed 
primarily  by  the  objective  of  the  analysis.  Geometric  symmetry  may  be  used 
to  advantage  in  laying  out  the  model. 

3.  How  to  represent  the  load  P.  Is  it  static,  transient,  or  steady-state?  Does  it 
vary  with  temperature,  displacement,  etc.? 

Engineering  expertise  is  needed  to  answer  these  questions,  based  on  the  nature  of 
the  structure,  the  excitations,  and  the  physical  phenomenon  being  modeled.  Each 
of  these  questions  is  now  discussed  in  turn. 

6.1.1  Five  Kinds  of  Finite  Element  Models 

The  kind  of  mesh  that  is  chosen  (coarse  or  fine)  and  the  types  of  elements  axe 
determined  primarily  by  the  objective  of  the  analysis.  We  may  identify  five  kinds 
of  NASTRAN  finite  element  models  which  axe  distinguished  mainly  by  the  kind  of 
elements  that  are  used  and  the  density  of  the  mesh.  The  classifications  axe  rather 
broad  and  overlap  substantially,  as  will  be  seen.  For  aircraft  structures,  only  three 
kinds  are  often  used: 

1.  Static  models 

2.  Dynamic  models 

3.  Aeroelastic  models 

Two  other  kinds  are  less  common  in  aircraft  modeling: 

4.  Heat  transfer  models 

5.  Acoustic  cavity  models 

Other  finite  element  codes  may  support  other  analysis  types,  but  not  likely  any  that 
would  be  of  interest  in  aircraft  analysis. 

Static  models  are  designed  to  provide  stress  and  deflection  predictions.  A  high 
degree  of  mesh  refinement  is  generally  required  for  stress  analysis  for  two  basic  rea¬ 
sons:  (l)  high  stress  gradients  are  commonly  observed,  and  (2)  when  displacements 
are  the  independent  variables,  sis  is  the  case  in  all  modem  finite  element  codes, 
stresses  are  computed  by  differentiating  the  approximate  displacements,  thus  intro¬ 
ducing  additional  error  which  must  be  compensated  for  by  increased  refinement. 

Dynamic  models  are  generally  used  to  compute  natural  frequencies  and  mode 
shapes.  They  may  also  be  used  to  compute  transient  or  steady-state  displacements 
and  accelerations.  Such  analyses  require  considerably  less  detail  than  static  models 
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since  mode  shapes  axe  usually  distributed  widely  over  the  structure  and  axe  thus 
insensitive  to  local  variations.  Two  exceptions  may  be  noted:  first,  when  gravity 
loads  axe  included,  there  must  be  sufficient  accuracy  in  the  mass  distribution  to 
produce  good  loads.  Second,  dynamic  stresses  may  also  be  of  interest.  In  this  case 
more  detail  must  be  introduced,  at  least  locally.  Also,  if  a  dynamic  analysis  is 
desired  but  only  a  static  model  is  available,  it  may  be  more  economical  to  pay  for 
the  additional  computer  time  required  to  carry  out  dynamic  analysis  with  a  static 
model  than  to  expend  the  manual  or  semi-automated  effort  required  to  simplify  the 
static  model. 

Aeroelastic  models  involve  a  mathematical  model  of  the  aerodynamics  as  well 
as  a  structural  model.  Aeroelastic  models  may  be  used  to  predict  static  aeroelastic 
stability  using  a  real  eigenvalue  solution,  and  for  dynamic  aeroelastic  stability. 

Heat  transfer  models  axe  generally  similar  to  static  models  with  regard  to 
the  kind  of  elements  and  their  distribution.  Heat  transfer  analysis  capabilities  axe 
included  in  NASTRAN  as  a  sort  of  byproduct  of  the  structural  analysis  capability. 
The  same  elements  axe  used,  but  NASTRAN  generates  heat  capacitance  and  con¬ 
ductance  matrices  instead  of  stiffness  and  mass  matrices.  Temperatures  take  the 
place  of  displacements  (thus  only  one  degree  of  freedom  per  node),  and  heat  sources 
and  sinks  take  the  place  of  loads.  Prediction  of  accurate  internal  heat  flux  distribu¬ 
tions  is  similar  to  prediction  of  accurate  stresses  in  that  generally  fine  meshes  axe 
required. 

Acoustic  cavity  models  appeared  in  NASTRAN  as  something  of  a  spur  capa¬ 
bility  which  is  not  particularly  relevant  to  aircraft  analysis,  but  is  mentioned  here 
only  for  completeness.  The  method  is  intended  for  analysis  of  structure-acoustics 
interaction  in  rocket  motors  with  axisymmetric  geometry. 


6.1.2  Symmetry 

Most  finite  element  models  axe  general  three-dimensional  models.  Others  exhibit 
special  symmetries  which  can  be  exploited  by  NASTRAN.  Reflective  symmetry 
is  handled  by  simple  constraints  applied  at  points  on  symmetry  planes.  Cyclic 
symmetry  is  handled  by  special  solution  methods  in  NASTRAN.  This  category 
covers  situations  having  rotational  symmetry;  that  is,  the  structure  looks  the  same 
after  rotation  about  an  axis  through  a  given  angle  (which  must  divide  360  degrees 
evenly).  Axisymmetry  is  a  limiting  case  of  cyclic  symmetry.  It  is  still  supported  in 
NASTRAN  by  special  elements  based  on  Fourier  series  expansions  in  the  circum¬ 
ferential  direction,  but  these  special  elements  may  be  considered  obsolete  smce  the 
introduction  of  the  more  general  cyclic  symmetry  capability. 

It  is  not  necessary  that  loads  be  symmetric  in  order  to  exploit  geometric  symme¬ 
try.  In  the  case  of  reflective  symmetry  about  the  plane  x  —  0,  for  example,  a  general 
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load  P  may  be  decomposed  into  symmetric  and  anti-symmetric  components;  i.e., 

P(x,y,z)  =Ps(x,y,z)  +  PA(x,y,z)  (4) 

where 

ps(*,y,z)  =  Ps(-«,y,z)  (5) 

Pa(z,V,z)  =  - PA(-x,y,z ) 

A  static  solution  may  be  obtained  by  solving 

KSUS  =  Ps 

and 

KaUa  =  PA 

and  recovering  the  total  solution 


U  =  US  +  UA 


for  the  x  >  0  side,  or 

U  =  US-UA 

for  the  x  <  0  side.  Even  though  two  solutions  are  required,  the  cost  is  less  them  a 
solution  of  the  full  model  because  the  matrix  decomposition  time  will  be  less  by  a 
factor  of  about  four. 

Similar  derivations  are  possible  for  solution  of  general  loads  acting  on  cyclic 
symmetric  structures  (Ref.  [l]). 


6.1.3  Equation  Types 

The  simplest  form  of  structural  analysis  is  static  analysis  in  which  we  solve  the 
linear  matrix  equation  shown  in  Eq.  2.  Static  analysis  is  justified  when  the  loads 
change  only  slowly.  In  most  cases,  flight  maneuver  loads,  for  example,  sire  treated 
as  quasi-static. 

In  linear  eigenvalue  analysis  we  solve 

(K  —  u>2M)U  =  0  (6) 

to  obtain  natural  frequencies  fi  =  u>i/(27r)  and  mode  shapes  U*.  This  kind  of 
analysis  is  very  important  because  frequencies  and  mode  shapes  tell  a  lot  about  the 
dynamics  of  a  structure. 

Static  stability  analysis  is  almost  never  required  in  aircraft  analysis,  but  is  men¬ 
tioned  here  for  completeness.  The  eigenvalue  buckling  problem 

(K  +  AKd)U  =  0 


(7) 
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is  formed  in  terms  of  the  “differential  stiffness”  Kd,  and  solved  for  the  lowest  root 
A.  Kd  is  the  linearized  incremental  stiffness  associated  with  a  particular  applied 
load. 

Dynamic  loads  may  be  classified  as  transient  or  steady-state.  'Transient  problems 
are  solved  by  forward  integration  of  the  equations  of  motion.  Steady-state  problems 
are  important  in  the  analysis  of  random  excitations.  Both  problems  are  usually 
formulated  in  terms  of  modal  superposition  in  which  multipliers  of  a  selected  set  of 
normal  modes  are  used  as  independent  degrees  of  freedom  rather  than  node  point 
displacements. 

Most  structural  analysis  is  based  on  linearized  equations  of  motion  and  linearized 
stress-strain  laws.  Nonlinearity  is  encountered  more  frequently  in  heat-transfer 
analysis,  as  when  temperature-dependent  thermal  properties  or  nonlinear  radiation 
laws  are  specified.  In  some  cases,  which  axe  seldom  encountered  in  aircraft  analysis, 
one  or  both  of  these  assumptions  may  not  unjustified.  In  these  cases  special  iterative 
analysis  methods  must  be  employed.  Nonlinear  analysis  is  usually  difficult  and  time- 
consuming,  requiring  an  analyst  with  special  skills. 


6.1.4  Definition  of  Loads 


Definition  of  loads  for  aircraft  analysis  is  basically  a  matter  of  defining  the  flight 
conditions  to  be  used.  Loads  usually  represent  a  certain  load  factor,  altitude,  air¬ 
speed,  gross  weight,  store  loads  and  many  other  considerations.  Ground  loads  for 
taxi  or  landing  landing  impact  may  also  have  to  be  simulated.  Obtaining  these  loads 
may  require  running  other  computer  codes  such  as  aerodynamic  or  taxi  programs. 
Ideally  a  finite  element  model  would  come  with  a  series  of  such  loads  representing 
the  conditions  which  are  critical  for  the  design  of  the  aircraft.  Unfortunately,  differ¬ 
ent  loads  axe  critical  for  different  parts  of  the  structure.  A  rolling  pullout  may  drive 
the  design  of  one  component,  while  a  different  maneuver  may  be  more  important 
to  another. 

The  manufacturer’s  stress  report  generally  lists  the  criteria  used  in  the  design 
of  each  component  and  shows  how  the  stress  analysis  was  performed.  These  stress 
reports  form  a  valuable  adjunct  to  a  finite  element  model,  but  they  are  usually 
pubhshed  in  limited  quantities  (only  a  few  copies  of  each  volume,  while  the  volumes 
may  run  to  a  hundred  or  more)  and  are  usually  not  available  to  most  engineers.  It 
is  recommended  that  the  Model  Center  have  a  copy  of  the  stress  reports  available. 
Loads  for  a  limited  number  of  well-defined  loading  conditions  should  be  part  of  the 
model. 
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6.2  NASTRAN  as  a  Standard 

NASTRAN  was  developed  originally  for  NASA  by  contractors.  Subsequently,  com¬ 
mercial  versions  appeared,  among  which  MSC/NASTRAN  is  predominant.  While 
several  other  commercial  finite  element  codes  exist,  none  of  them  competes  seri¬ 
ously  in  the  aerospace  industry.  COSMIC  NASTRAN,  the  original  government 
version,  still  exists  and  is  used  at  a  few  government  installations,  although  we  know 
of  no  aerospace  companies  that  use  it.  Some  aerospace  companies  continue  to  use 
in-house  finite  element  codes,  but  nearly  all  use  NASTRAN  at  least  as  an  adjunct 
to  their  in-house  code.  FDL’s  ASTROS  program  also  uses  NASTRAN  input  for¬ 
mat.  These  facts  make  it  reasonable  to  specify  NASTRAN  format  in  the  proposed 
Mil-Standard,  and  also  to  adopt  NASTRAN  format  for  storage  of  models  in  the 
Model  Center. 

The  question  remains:  which  NASTRAN  format?  The  survey  results  in  Section 
3  suggest  that  most  Air  Force  users  would  prefer  MSC/NASTRAN  format.  This 
is  probably  true  of  aerospace  companies  as  well.  However,  FDL  has  stated  a  pref¬ 
erence  for  COSMIC  NASTRAN,  and  for  this  reason,  the  Mil-Standard  outlined  in 
Section  6.6  requires  contractors  to  translate  their  models  into  COSMIC  NASTRAN 
format.  The  outline  also  calls  for  contractors  to  deliver  their  models  in  their  origi¬ 
nal  format.  The  first  reason  for  this  requirement  is  that  some  information  may  be 
lost  in  the  process  of  translating  from  the  original  format  to  COSMIC  NASTRAN 
format.  The  Model  Center  ought  to  have  the  original  data  as  well  as  the  translated 
data  in  order  to  understand  what  approximations  were  made  in  the  translation  pro¬ 
cess.  Such  approximations  can  be  trivial  or  they  may  seriously  effect  the  results 
predicted  by  the  model.  Second,  many  models  will  have  been  developed  originally 
in  MSC/NASTRAN  format,  and  many  (probably  most)  organizations  that  request 
models  from  the  Center  will  want  them  in  MSC/NASTRAN  format.  The  Cen¬ 
ter  ought  to  at  least  keep  the  MSC/NASTRAN  versions  along  with  the  translated 
versions  so  that  users  who  want  MSC/NASTRAN  format  need  not  translate  them 
back  mto  that  format.  In  Section  7  we  show  that  the  proposed  database  software 
is  equally  capable  of  storing  COSMIC  NASTRAN  or  MSC/NASTRAN  data.  In 
fact,  it  can  store  data  for  many  other  codes  with  somewhat  reduced  documentation 
capability. 


6.3  Pre-  and  Post-Processors 

Finite  element  pre-processors  axe  programs  (usually  graphics-oriented)  that  can  be 
used  to  generate  finite  element  models  in  a  semi-automated  manner.  Generally 
speaking,  users  define  certain  key  nodes  (at  comers,  for  example)  and  then  specify 
that  a  mesh  of  interior  nodes  and  elements  is  to  be  filled  in  according  to  certain 
specifications. 
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Automatic  mesh  generation  is  convenient  when  applicable,  but  geometric 
irregularities  in  a  structure  may  limit  its  usefulness.  In  these  cases  manual  definition 
of  many  nodes  and  elements  will  still  be  necessary  In  these  cases,  pre-processors  are 
still  valuable  for  the  ability  to  view  the  model  with  interactive  control  of  rotation, 
zoom,  hidden  surface  removal,  etc. 

Pre-processors  generally  accept  commands  either  from  the  keyboard  or  from 
command  files.  Since  keyboard  commands  are  not  recorded  permanently,  command 
files  are  the  best  way  to  generate  models  in  production  work.  In  these  cases  the 
user  may  not  pay  much  attention  to  the  bulk  data  file  that  is  generated  by  the  pre¬ 
processor,  considering  the  pre-processor  command  file  to  be  the  real  source  of  the 
model  and  the  focus  of  his  effort.  In  other  cases,  however,  manual  editting  of  the 
bulk  data  may  be  necessary.  If  a  user  makes  non-repeatable  (or  difficult-to-repeat) 
changes  to  a  bulk  data  deck,  he  has  then  invalidated  the  pre-processor  command  file, 
making  it  difficult  or  impossible  to  go  back  to  the  pre-processor  and  make  changes 
at  that  level.  This  also  leads  to  the  possibility  that  some  unsuspecting  future  user 
may  assume  that  the  command  file  is  still  current.  Thus  we  may  distinguish  three 
situations  in  the  use  of  pre-processors: 

1.  Where  little  or  no  editting  of  the  bulk  data  is  required,  the  pre-processor 
command  file  should  be  considered  the  source  of  the  model.  Any  editting  of 
the  bulk  data  should  be  done  in  a  repeatable  manner.1 

2.  Where  extensive  editting  of  the  bulk  data  is  required,  it  may  be  best  to  “bum 
bridges,”  abandoning  the  pre-processor  once  extensive  changes  to  the  bulk 
data  have  been  made. 

3.  Borderline  cases  have  to  be  handled  with  judgement,  but  it  must  always  be 
clear  whether  the  pre-processor  command  file  is  current  or  not. 

NASTRAN  has  been  selected  as  a  standard  finite  element  code  for  this  effort 
(see  6.2).  No  such  choice  is  possible  for  pre-processors,  however,  since  no  one  code 
has  reached  the  position  of  prominence  that  NASTRAN  has  reached  among  finite 
element  codes.  Therefore,  no  attempt  will  be  made  to  develop  standards  that  relate 
to  pre-processing  codes. 

6.4  Validation  of  Models 

It  is  very  important  to  establish  confidence  in  a  finite  element  model,  especially 
one  obtained  from  another  organization.  Validation  of  models  is  by  no  means  an 
exact  science,  but  depends  partly  on  experience  and  judgement.  Nor  is  validation 
a  simple  yes/no  judgement.  Ideally,  an  estimate  of  the  accuracy  of  the  model  is 


1The  use  of  HISTORIAN,  discussed  in  Section  7,  would  be  ideal  for  this  purpose 
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desirable  (e.g.,  within  5%  or  within  50%),  or  for  dynamics,  the  range  of  frequencies 
over  which  it  is  valid. 

As  is  mentioned  in  Section  8.3,  there  are  some  mathematical  theorems  regarding 
convergence  of  finite  element  models  with  increasing  mesh  refinement,  but  these  are 
hardly  ever  useful  in  practice.  For  one  thing,  there  is  often  not  much  choice  about 
where  to  locate  node  points.  Having  defined  node  points  at  all  the  places  dictated 
by  the  geometry  of  the  structure  (i.e.,  at  stiffeners,  cutouts,  thickness  changes,  etc.), 
the  analyst  often  finds  his  “budget”  of  node  points  exhausted,  or  nearly  so. 

There  are  a  number  of  diagnostic  checks  performed  by  NASTRAN  that  should 
be  checked  as  a  first  step  in  validating  a  model.  Assuming  a  model  is  free  of  simple 
format  errors  and  typographical  errors,  the  next  validation  step  would  be  generation 
of  plots.  These  can  be  used  to  check  visually  for  elements  that  are  misshapen,  node 
points  out  of  place,  etc.  Also,  the  diagnostic  program  called  RATS  can  be  used  to 
check  models  for  bad  or  questionable  geometry.  Next,  simple  static  loads  can  be 
applied.  NASTRAN  prints  several  diagnostic  messages  that  can  help  uncover  errors 
in  element  connections,  poor  constraint  sets,  etc.  Simple  node  point  singularities 
are  detected  automatically.  More  complex  mechanisms  or  near-mechanisms  can 
be  detected  by  a  matrix  conditioning  number  (ratio  of  maximum  factor  diagonal 
to  matrix  diagonal).  Acceptable  values  for  this  nondimensional  ratio  range  from 
105  to  107.  A  residual  error  ratio  which  is  calculated  for  static  analysis  can  also 
point  to  stiffness  singularities.  In  dynamic  analysis,  spurious  strain  energy  in  rigid 
body  modes  can  indicate  improper  constraint  sets.  All  these  diagonistics  should  be 
checked  where  applicable. 

Loads  often  provide  a  good  standard  with  which  to  validate  models.  A  set  of 
known  loads  that  provide  a  set  of  known  or  measured  displacements  for  the  actual 
structure  provide  a  benchmark  that  can  be  used  to  check  the  model  for  continuity, 
connectivity,  and  constraints.  Correlation  of  such  data  provides  confidence  that  the 
model  is  an  accurate  representation  of  the  real  structure.  Confidence  in  the  model 
is  a  very  important  factor  in  finite  element  analysis,  since  there  can  be  errors  that 
are  not  easy  to  detect.  Another  method  of  providing  loads  to  run  a  check  on  a 
model  is  the  use  of  structural  influence  coefficients  using  point  loads  as  was  done 
during  the  creation  of  the  the  B-1A  model.  This  is  useful  if  there  is  sufficient  data 
to  check  against.  If  vibration  data  is  available,  from  a  ground  vibration  test  for 
example,  a  normal  modes  analysis  of  the  model  can  help  verify  the  stiffness  of  the 
model  if  the  mass  is  known  to  match. 

In  dynamic  problems,  mode  shapes  should  be  checked  thoroughly  by  generating 
plots.  Improper  stiffness  and  masses  will  often  show  up  as  unrealistic  mode  shapes. 
Also,  the  diagnostic  messages  that  are  provided  with  the  various  eigenvalue  solution 
methods  should  be  checked  to  insure  that  no  roots  have  been  skipped. 

Validating  a  model  can  require  a  great  deed  of  effort.  As  the  survey  results 
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reported  in  Section  3  indicate,  Air  Force  agencies  receiving  models  from  contractors 
often  have  no  practical  choice  but  to  assume  that  the  contractor  has  created  a  good 
model.  It  can  be  argued  that  manufacturers  have  the  best  data  and  knowledge  of 
the  structure  and  so  the  models  the  create  ought  to  be  good.  Of  course,  a  major 
goal  of  the  present  effort  is  to  make  it  unnecessary  to  accept  models  on  faith,  by 
requiring  evidence  of  validation  along  with  delivery  of  models. 


6.5  Supporting  Documentation 

The  value  of  a  finite  element  model  depends  heavily  on  the  availability  of  support¬ 
ing  documentation,  especially  when  a  model  is  delivered  from  one  organization  to 
another.  Documentation  may  include  reports,  plots,  sketches,  and  comments  in  the 
bulk  data  deck. 

6.6  Mil-Standard  for  Delivery  of  Finite  Element  Models 

The  need  for  a  standard  to  require  developers  of  Air  Force  aircraft  to  deliver  the 
finite  element  models  that  they  generate  has  already  been  discussed  in  Section  2. 
In  this  section  we  discuss  the  proposal  for  a  standard  in  more  detail.  The  outline 
below  is  based  largely  on  Venkayya^  proposed  (Ref.  [2]),  but  with  some  additional 
ideas  and  a  somewhat  different  arrangement. 

6.6.1  Background  on  Mil-Standards 

Typically  a  standard  imposes  requirements  and  performance  standards  and  rec¬ 
ommends  techniques  for  compliance.  Structural  requirements  for  aircraft  are  con¬ 
tained  m  two  basic  documents,  Mil-A-87221  and  Mil-Std-1530A.  A  Mil-Standard 
for  the  acquisition  of  finite  element  models  should  ideally  be  a  separate  document, 
although  it  could  conceivably  be  made  part  of  Mil-A-87221,  during  its  next  review 
and  update  cycle.  The  requirements  of  such  a  Mil-Standard  have  been  addressed 
by  the  Air  Force.  A  sample  Data  Item  Description  was  drafted  in  1985  (Ref.  [2]) 
and  addresses  in  detail  the  type  of  data  that  must  be  supphed. 

Through  the  MIL-PRIME  program,  the  Air  Force  has  been  working  to  stream¬ 
line  the  acquisition  process  by  improving  the  quality  of  specifications  and  standards 
applied  to  individual  contracts.  The  goal  is  a  to  eliminate  overspecification  by  tailor¬ 
ing  documents  to  specific  weapons  systems.  Each  MIL-PRIME  document  consists 
of  a  specification  or  standard  tailored  to  the  specific  situation.  An  associated  hand¬ 
book  contains  rationale,  guidance,  and  lessons  learned  for  each  requirement  and 
its  associated  verification.  By  the  end  of  1987,  fifty-four  MIL-PRIME  development 
documents  were  available  for  program  use  (Ref.  [6]).  In  the  past,  delivery  of  finite 
element  models  has  generally  not  been  a  requirement,  even  though  the  contractor 
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may  have  been  paid  for  the  work  involved.  If  such  delivery  is  to  made  a- require¬ 
ment,  a  stringent  Mil-Standard  must  be  developed  to  ensure  that  models  contain 
all  the  documentation  needed  to  insure  their  usefulness.  The  requirements  of  this 
Mil-Standard  should  be  such  that  it  would  not  require  or  even  accept  tailoring  to  an 
individual  program.  The  temptation  to  water  down  the  model  requirements  must 
be  avoided. 

The  creation  of  a  Mil- Specification  or  standard  is  an  involved  process.  It  is 
certainly  beyond  the  scope  of  Phase  I  to  try  to  create  such  a  document.  However, 
since  the  authors  have  given  some  consideration  to  the  need  for  such  a  document, 
a  rough  outline  of  such  a  Mil-Standard  based  on  the  format  of  Mil-Std  1530  is 
suggested. 


6.6.2  Outline  of  the  Proposed  Mil-Standard 

This  outline  is  based  on  Venkayya’s  DID  (Ref.  [2])  with  some  added  material  and 
a  somewhat  different  order  of  topics. 

1.  Scope 

1.1  Purpose.  The  purpose  of  this  standard  is  to  describe  the  Air  Force 
Model  Program,  define  the  overall  requirements,  and  specify  methods  of 
contractor  compliance.  This  standard  shall  be  used  by: 

1.1.1  Contractors  in  developing  sin  airframe  for  a  particular  weapon  or 
system 

1.1.2  Government  personnel 

1.2  Applicability.  This  standard  is  directly  applicable  to: 

1.2.1  Future  airplane  systems 

1.2.2  Airplane  systems  procured  by  the  Air  Force,  but  developed  under 
another  agency  such  as  the  USN  or  the  FA  A. 

1.2.3  Airplanes  undergoing  a  major  modification. 

2.  Referenced  Documents 

2.1  COSMIC  NASTRAN  manuals 

2.2  ANSI  specs  for  ASCII  tape  format 

2.3  (others  as  required) 

3.  Definitions 


3.1  Finite  Element  Model 
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3.2  Analysis  types 

3.2.1  Static  Analysis 

3.2.2  Dynamic  Analysis 

3.2.2.1  Undamped  normal  modes 

3.2.2.2  Damped  normal  modes 

3.2.2.3  Transient  analysis 

3.2.2.4  Steady-state  frequency  response  analysis 

3.2.2.5  Random  analysis 

3.2.3  Heat  Transfer  Analysis 

3.2.3.1  Linear  steady-state  analysis 
3  2.3.2  Non-linear  steady-state  analysis 

3. 2.3.3  Linear  transient  analysis 

3.2. 3.4  Non-linear  steady-state  analysis 

3.2.4  Aeroelastic  Analysis 

3  2.5  Combined  Structure-Control  system  Analysis 

3.3  Meta-models 

4.  Model  Delivery  Requirements 

4.1  The  contractor  shall  deliver  to  the  Air  Force  all  finite  element  models 
that  were  used  in  verifying  structural  integrity. 

4.2  Contractors  shall  not  be  required  to  use  any  particular  finite  element 
code  m  their  analysis  work.  Models  shall  be  delivered  in  the  format  used 
by  their  particular  code.  If  some  code  other  than  COSMIC  NASTRAN 
is  used,  a  translated  version  of  each  model  shall  also  be  provided.  The 
translated  version  will  conform  to  the  input  requirements  of  COSMIC 
NASTRAN,  In  cases  where  COSMIC  NASTRAN  does  not  provide  a 
capability  supported  by  the  contractor’s  in-house  code,  the  closest  capa¬ 
bility  in  COSMIC  NASTRAN  will  be  substituted  where  possible. 

4.3  Contractors  shall  deliver  to  the  Air  Force  any  meta-models  that  were 
used  in  generating  the  finite  element  models  that  axe  delivered.  The 
contractor  shall  identify  the  pre-processing  code  for  which  the  meta¬ 
model  was  developed.  Meta-models  shall  be  in  the  form  of  ASCII  input 
files,  as  used  by  the  contractor.  There  will  be  no  translation  requirement. 

4.4  All  models  must  be  delivered  on  standard  half-inch  computer  tape,  in 
ASCII  format.  The  contractor  may  use  a  different  format  subject  to 
approval  by  the  project  officer.  Tapes  must  be  accompanied  by  a  written 
fist  of  the  contents  of  each  file  on  the  tape. 
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5.  Documentation  Requirements 

5.1  General.  For  each  model  that  is  delivered,  a  complete  set  of  documenta¬ 
tion  will  be  required. 

5.2  Identification  of  the  aircraft.  For  each  model  that  is  delivered,  the  fol¬ 
lowing  shall  be  documented: 

5.2.1  Name  and  configuration  version. 

5.2.2  Identification  of  documents  and  drawings  from  which  the  model 
was  generated.  Copies  of  these  documents  and  drawings  shall  be 
provided  if  they  are  not  otherwise  available  to  the  Government. 

5.2.3  A  key  diagram  showing  the  location  of  the  component  being  mod¬ 
eled  in  relation  to  the  rest  of  the  structure. 

5.3  Documentation  applicable  to  all  model  types 

5.3.1  A  brief  discussion  of  the  physical  phenomenon  being  modeled. 

5.3.2  A  discussion  of  the  fineness  or  coarseness  of  the  model. 

5.3.3  Any  symmetry  conditions  that  were  used  to  advantage,  including 
the  type  of  symmetry  (reflective  or  rotational)  and  its  location. 

5.3.4  Documentation  of  element  types.  A  list  of  element  types  used  and 
the  rationale  for  each  shall  be  provided. 

5.3.5  “Smearing”  approximations.  A  common  practice  in  finite  element 
modeling  is  to  represent  areas  with  complex  geometry  (such  as  sur¬ 
faces  with  small  holes)  by  equivalent  uniform  sections.  Where  such 
practices  have  been  employed,  they  shall  be  explained  here. 

5.3.6  Material  properties.  All  materials  properties  shall  be  explained 
and  referred  to  applicable  Mil-Standards,  with  reasons  given  for  any 
deviations  from  those  standards. 

5.3.7  Documentation  of  constraint  sets.  For  each  set  of  constraints  (bound¬ 
ary  conditions),  an  explanation  of  the  reason  for  the  constraints.  If 
constraint  sets  are  to  be  combined  (by  NASTRAN  SPCADD  cards), 
this  must  be  documented. 

5.3.8  Validation.  The  contractor  shall  explain  how  the  model  was  val¬ 
idated.  This  discussion  encompasses  diagnostic  messages  from  the 
finite  element  code,  comparison  to  known  or  expected  results,  and 
reference  to  test  data  if  such  is  available. 

5.4  Documentation  of  static  models. 

5.4.1  Load  sets.  For  each  set  of  loads,  an  explanation  of  each  shall  be 
provided,  including  a  categorization  (static,  gravity,  thermal,  cen¬ 
trifugal,  or  other  special  situations). 
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5.4.2  If  load  sets  axe  to  be  combined  by  NASTRAN  (using  LOAD  bulk 
data  cards),  these  combined  sets  must  be  documented. 

5.4.3  Where  nonlinear  analysis  is  employed,  information  specific  to  the 
nonlinear  aspects  must  be  presented. 

5.4.3.1  The  nature  of  the  nonlinearity  (finite  displacements,  nonlin¬ 
ear  elasticity,  plasticity)  and  the  reason  why  nonlinear  behavior 
was  expected. 

5.4.3. 2  Control  parameters  that  were  used  in  the  iterative  solution, 
and  evidence  of  convergence 

5.5  Documentation  of  dynamic  models. 

5.5. 1  The  frequency  range  over  which  the  model  is  valid. 

5.5.2  The  reduction  process  that  was  used  (if  any).  This  may  include 
subspace  iteration,  generalized  dynamic  reduction,  or  Guvan  reduc¬ 
tion.  In  the  latter  case,  an  explanation  of  the  analysis-set  degrees  of 
freedom  shall  be  provided. 

5.5.3  Any  nonstructural  masses  that  were  used. 

5.5.4  For  dynamic  response  analysis,  the  following  must  be  provided. 
These  requirements  apply  to  both  transient  analysis  and  steady-state 
frequency  response  and  random  analysis. 

5.5.4.1  The  source  of  the  loading,  and  the  way  in  which  its  frequency 
distribution  or  time  history  were  derived. 

5.5.4.2  The  kinds  of  damping  that  were  used  (viscous  or  structural) 
and  how  values  were  arrived  at. 

5.5.4.3  Dynamic  solution  parameters.  For  either  transient  or  steady- 
state  analyses,  where  modal  superposition  is  used,  the  frequency 
at  which  modes  were  truncated  shall  be  justified. 

5.5.4.3.1  For  transient  analyses,  an  explanation  of  the  time  step 
value  that  was  chosen. 

5.5.4.3.2  For  steady-state  frequency  response  analysis,  an  expla¬ 
nation  of  the  frequency  increment. 

5.5.5  Aeroelastic  analyses.  When  aeroelastic  analyses  are  performed,  the 
structures  model  shall  be  described  as  required  under  sections  5.3 
and  5.4.  This  section  pertains  to  documentation  of  the  aerodynamic 

5.5.5.1  The  aerodynamic  theory  being  employed  shall  be  described 
(piston  theory,  etc.) 

5. 5. 5. 2  The  lifting  surfaces  for  which  aerodynamics  are  being  mod¬ 
eled  shall  be  enumerated  and  described  physically. 
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5.5.5.3  The  aerodynamic  parameters  shall  be  enumerated  (altitude, 
mach  number,  etc.) 

5. 5.5.4  The  kinds  of  force  and  displacement  transformations  between 
the  structural  grid  and  the  aerodynamic  grid  shall  be  explained. 

5.5.5.5  Provisions  for  rigid  body  modes,  if  any,  in  flutter  analyses. 

5.5.5.6  Where  aeroservoelastic  analysis  is  employed  or  anticipated, 
data  must  be  presented  in  a  state  space  formulation. 

5.6  Documentation  of  heat  transfer  models 

5.6.1  Derivation  of  material  properties  with  references  to  Mil-Standards. 

5.6.2  Heat  sources  and  sinks 

5.6.3  Boundary  conditions 

5.6.4  Analysis  type  (transient  or  steady-state;  linear  or  nonlinear) 

5.6.5  Transfer  of  temperatures  to  static  stress  analyses,  if  applicable. 

5.7  Special  analysis  types.  This  section  shall  cover  any  special  analysis 
types  not  enumerated  above,  including  interdisciplinary  analyses  such 
as  structure-control  system  or  fluid-structure  analyses.  A  full  explana¬ 
tion  of  the  coupling  method  shall  be  provided. 


6.6.3  Comments  on  the  Outline 

No  attempt  has  been  made  to  formulate  proper  legal  phrases  for  a  Mil-Standard. 
This  is  a  matter  for  specialists. 

This  outline  is  based  on  Venkayya’s  DID  (Ref.  [2]).  In  one  section,  he  spells 
out  the  ingredients  of  a  static  model  (nodes,  elements,  material  properties,  etc.). 
We  have  not  included  this  because  it  gives  the  appearance  of  a  specification  about 
how  to  create  models.  The  intent  here  is  to  specify  only  delivery  requirements  and 
not  guidelines  for  creating  models.  We  assume  that  the  models  have  already  been 
validated  and  thus  they  must  include  all  the  necessary  ingredients. 

Acoustic  cavity  analysis  was  not  mentioned  specifically  in  Article  5  since  it  is 
seldom  applicable  to  aircraft  analysis.  Such  analyses  would  be  incorporated  under 
in  Article  5.7. 

Meta-models  were  mentioned  in  Article  4.3,  and  are  discussed  in  Section  8.  No 
standards  can  reasonably  be  imposed  regarding  met  a- models.  However,  delivery  of 
this  data  is  considered  valuable  even  if  it  is  for  a  code  which  the  Air  Force  does  not 
have.  It  could  be  useful  merely  for  gaining  additional  understanding  of  the  model 
that  it  generates. 
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6.6.4  Costs 

It  must  be  understood  that  these  requirements  will  impose  costs  upon  contractors 
which  will  ultimately  be  reflected  in  their  bids.  •  Superficially,  it  might  seem  that 
the  only  costs  involved  would  be  writing  a  tape,  bundling  up  some  documents,  and 
shipping  them,  and  these  would  be  nominal.  In  fact,  the  real  costs  would  result 
from  contractors’  perceptions  (real  or  imagined)  that  they  were  being  subject  to 
increased  exposure  and  liability.  They  would  thus  expend  extra  effort  in  verifying 
and  documenting  any  models  that  were  to  be  delivered. 

It  is  very  difficult  to  quantify  such  costs.  However,  it  is  reasonable  to  assume 
that  they  would  be  a  fraction  of  what  would  be  charged  under  a  contract  that  called 
for  generation  and  development  of  a  model  of  the  same  system. 

Another  relevant  point  is  the  benefits  that  would  accrue  to  both  the  contractor 
and  the  Air  Force  as  a  result  of  these  requirements,  aside  from  the  delivery  per 
se.  The  authors  know  from  long  experience  that  having  to  explain  a  model  to  a 
colleague  is  one  of  the  most  effective  ways  of  debugging  it.  This  is  so  even  when 
the  colleague  merely  sits  and  listens.  Another  fact  of  life  is  that  developers,  having 
invested  so  much  energy  in  a  model,  tend  to  assume  it  is  complete  before  there 
have  been  sufficient  checks.  It  is  quite  likely  that  m  documenting  and  verifying  a 
model  in  preparation  for  delivery,  contractors  would  discover  shortcomings  that  had 
previously  not  come  to  light.  Such  discoveries  could  prevent  potentially  catastrophic 
problems  with  the  models.  In  any  event,  the  additional  efforts  would  increase  the 
contractor’s  confidence  in  his  own  model. 

Another  wav  to  approach  the  costs  issue  is  to  assume  for  a  moment  that  delivery 
requirements  had  been  m  effect  all  along  and  that  someone  was  proposing  eliminat¬ 
ing  them  in  order  to  save  money.  They  would  have  to  argue  that  contractors  would 
bid  lower  because  they  could  take  less  care  in  their  modeling  and  could  skip  some 
of  the  documentation  and  verification  efforts.  Such  arguments  would  not  likely  be 
taken  seriously.  This  would  be  especially  true  if  the  proposed  Model  Center  had 
been  m  existence  for  some  time,  and  if  models  delivered  by  contractors  had  been 
used  to  advantage  by  the  Air  Force. 
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7.  A  Proposed  Database  for  Finite  Element 
Models 

The  basic  function  of  the  envisioned  Center  is  to  collect,  process,  store,  and  dis¬ 
tribute  finite  element  models  and  information  about  those  models.  The  Center  will 
not  be  successful  unless  this  information  can  survive  after  the  personnel  who  gen¬ 
erate  it  have  left.  Typically,  developers  of  finite  element  models  (also  developers  of 
computer  software)  do  not  realize  the  extent  to  which  they  rely  on  memory,  nor  how 
quickly  they  cam  forget.  This  usually  becomes  clear  only  when  work  is  interrupted 
(by  a  vacation,  for  example).  A  good  way  to  address  this  problem  is  by  thoughtful 
design  of  information-handling  systems.  The  software,  procedures,  rules,  etc.,  that 
constitute  such  systems  should  do  the  following: 

1.  Anticipate  the  kinds  of  descriptive  information  that  is  most  useful; 

2.  Encourage  users  to  enter  such  descriptions  when  new  models  or  modifications 
are  entered; 

3.  Structure  the  data  in  a  manner  that  reflects  the  way  engineers  generate  and 
use  it. 

This  does  not  imply  that  expensive  or  elaborate  systems  will  be  needed.  It  does 
mean  that  the  system  design  should  be  guided  by  engineers  who  are  experienced 
users  of  finite  element  software,  and  should  be  implemented  by  personnel  who  know 
how  best  to  implement  these  ideas  using  existing  software  wherever  possible. 

The  rest  of  this  section  discusses  the  problems  involved  in  maintaining  and 
documenting  finite  element  models,  reviews  past  approaches  to  the  problem,  and 
recommends  a  software  solution  that  will  be  simple,  effective,  and  efficient. 


7.1  Past  Approaches  to  Model  Maintenance 

The  problems  faced  by  engineers  who  must  update  and  maintain  finite  element 
models  are  very  similar  to  those  faced  by  software  developers  who  must  maintain 
source  code.  Both  cases  involve  maintenance  of  large  ASCII  files  which  are  subject 
to  continuing  modification  and  the  associated  problems  of  tracking,  verification, 
etc.  Also,  small  changes  can  produce  subtle  and  unexpected  changes  in  the  results 
produced  by  the  software  or  the  model.  As  computer  hardware  developed  over 
the  years,  so  did  the  methods  available  for  source  code  maintenance,  and  the  same 
methods  have  been  adapted  to  some  extent  for  finite  element  models. 

At  first,  punched  cards  were  used  exclusively.  While  physical  possession  of  a 
card  deck  provided  a  certain  sense  of  confidence,  there  were  many  problems.  Card 
decks  were  difficult  to  identify  and  were  vulnerable  to  physical  deterioration.  If  one 


40 


7.  A  PROPOSED  DATABASE  FOR  FINITE  ELEMENT  MODELS 


wanted  to  create  a  modified  version  of  a  model  and  still  save  the  original,  one  could 
always  get  the  cards  duplicated  and  modify  the  copy.  But  then  the  changes  would 
probably  not  be  documented,  and  subsequent  changes  to  the  original  might  not  be 
applied  to  the  copy. 

Later,  magnetic  tapes  became  available  to  store  card-image  files  such  as  source 
code  or  finite  element  models.  Manufacturers  provided  utilities  that  enabled  users 
to  make  corrections  to  a  basic  file  on  tape  without  destroying  the  original.  SLP 
on  the  UNIVAC  1107  was  one  such  system;  IBM  supplied  another  for  its  7094. 
However,  during  the  late  1960’s,  Control  Data  mainframes  (6400,  6600)  became 
predominant  in  scientific  computing.  Most  finite  element  analysis  was  carried  out 
on  these  machines,  and  most  users  took  advantage  of  CDC’s  UPDATE  utility  for 
model  maintenance.  This  approach  still  relied  on  punch  cards  as  the  primary 
input  medium,  but  provided  users  with  a  means  for  tracking  modifications  and 
for  retaining  multiple  modifications  of  a  single  basic  file. 

The  basic  sequence  of  operations  with  UPDATE  was  as  follows: 

First,  a  user  partitioned  his  source  file  into  sections  called  “decks.”  Each  deck 
was  given  a  name  which  was  punched  on  a  *DECK  card.  Deck  names,  if  chosen 
wisely,  helped  somewhat  in  documenting  the  model 

Next,  the  source  file  was  submitted  to  UPDATE  which  read  the  deck  and  created 
a  “program  library”  file  which  was  stored  on  tape  (or  later,  on  permanent  disk 
files).  File  names  for  these  program  libraries  provided  another  tag  that  could  help 
document  models.  UPDATE  also  produced  a  printed  listing  showing  a  unique 
identifier  for  every  line  in  the  file.  This  listing  had  to  be  retained  by  the  user.  Wise 
users  also  kept  their  original  card  decks  because  frequent  system  problems  in  those 
days  made  data  storage  on  magnetic  media  unreliable. 

Then,  in  order  to  make  corrections,  a  user  prepared  a  “correction  deck”  which 
was  identified  by  a  correction  set  name  (another  opportunity  for  identification). 
Each  such  deck  consisted  of  *IN  SERT  and  ^DELETE  directives  which  referred  to 
cards  in  the  original  deck  by  their  sequence  numbers.  By  submitting  both  the 
“old  program  library”  and  the  correction  deck,  UPDATE  could  produce  a  modified 
source  file  that  could  be  submitted  to  a  compiler  or  a  finite  element  code.  The 
obvious  advantage  was  that  these  changes  were  reversible.  Furthermore,  one  could 
maintain  several  independent  correction  decks  (corresponding  to  various  damage 
cases,  for  example)  that  could  each  reference  the  original  model. 

It  often  happened  that  corrections  became  so  numerous  that  the  correction  decks 
began  to  rival  the  original  deck  in  size.  In  these  cases  one  could  direct  UPDATE  to 
write  a  “new  program  library”  (NEWPL)  which  included  the  indicated  corrections. 
Deleted  cards  were  not  really  removed  from  these  libraries,  but  instead  were  marked 
“inactive.”  Thus  even  after  saving  a  NEWPL,  one  could  reverse  the  effect  of  cor¬ 
rection  sets  by  means  of  *YANK  and  *YANKDECK  directives.  An  irreversible  step 
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was  also  possible  in  which  one  created  a  resequenced  “source”  file. 

The  process  of  creating  update  correction  sets  was  still  somewhat  tedious,  how¬ 
ever.  Users  had  to  prepare  UPDATE  directives  as  well  as  revised  data  cards,  and 
then  keypunch  them  (or  submit  filled-in  forms  to  the  keypunch  department).  In  the 
late  1970’s,  video  terminals  became  available;  screen-oriented  editors  soon  followed. 
These  utilities  made  it  much  easier  to  make  corrections  because  one  could  see  the 
corrected  file  as  it  was  changed  on  the  screen,  and  it  was  not  necessary  to  retype 
whole  lines  if  only  a  few  characters  were  to  be  changed.  Users  embraced  these 
screen-oriented  systems  enthusiastically,  but  there  were  still  problems.  With  only  a 
screen  editor  to  make  changes,  users  lost  the  discipline  provided  by  UPDATE:  there 
was  no  tracing  and  no  reversibility  except  to  the  extent  that  users  saved  backup 
copies  of  old  versions  of  files. 

The  introduction  of  preprocessors  such  as  PATRAN,  GIFTS,  GRASP,  etc.,  has 
increased  productivity  in  finite  element  modeling,  but  these  packages  in  themselves 
have  not  solved  the  logistical  problems  of  finite  element  modeling.  If  anything,  in 
adding  a  new  step  to  the  modeling  process,  they  have  introduced  new  pitfalls.  That 
is,  it  is  possible  to  generate  a  model  with  a  preprocessor  and  then  modify  it  manually. 
After  making  manual  changes,  one  might  want  to  return  to  the  preprocessor  to  make 
changes  at  that  level,  at  which  point  the  manual  changes  would  be  lost. 

With  the  proliferation  of  computer  power  both  in  the  PC  world  and  in  minicom¬ 
puters,  a  number  of  source  code  maintenance  tools  have  become  available.  Many  of 
these  have  advanced  features  such  as  macro  expansion,  “include”  files,  and  screen 
editors  oriented  toward  a  particular  high-level  language.  Most  of  these  features  are 
not  relevant  to  finite  element  models.  One  could  of  course  envision  a  bulk  data- 
oriented  screen  editor,  but  such  a  development  is  beyond  the  scope  of  this  effort,  and 
besides,  would  tend  to  counter  the  trend  toward  model  generation  by  automated 
pre-processors. 

The  solution  that  is  presented  in  the  following  paragraphs  was  motivated  by 
a  desire  to  have  both  the  advantages  of  UPDATE  and  the  advantages  of  a  screen 
editor.  Another  goal  was  to  handle  all  user  interaction  through  a  friendly,  screen- 
oriented  interface. 

7.2  The  HISTORIAN /DATATRIEVE  Approach 

Among  the  engineers  who  contributed  to  this  effort,  three  (Dr.  Gibson,  Mr.  Negaard, 
and  Mr.  James)  are  experienced  users  of  NASTRAN.  Over  the  years,  they  have 
gained  experience  with  and  understanding  of  the  engineering  and  mathematical 
aspects  of  finite  element  modeling.  More  important  for  our  purposes  here,  they  know 
from  first-hand  experience  the  logistical  problems  that  this  proposed  addresses.  All 
three  have  had  to  work  with  models  developed  by  others,  and  have  experienced  the 
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intense  frustration  that  can  arise  when  these  models  are  poorly  documented.  They 
also  understand  the  kinds  of  revisions  or  variations  that  engineers  typically  apply 
to  models,  such  as  error  corrections,  new  load  cases,  different  materials,  damage 
cases,  etc. 

Mr.  Tenorio  has  been  applying  database  technology  to  engineering  data  man¬ 
agement  problems  for  many  years.  While  he  knows  the  computer  science  aspects 
of  database  technology  thoroughly,  he  also  understands  the  user’s  point  of  view. 
In  particular,  he  knows  that  users  generally  have  developed  certain  approaches  to 
their  problems,  and  that  these  approaches  should  be  respected  even  though  they 
may  not  be  optimal  from  a  computer  science  point  of  view. 

The  database  approach  recommended  here  was  developed  jointly  by  Mr.  Tenorio, 
Dr.  Gibson,  and  Mr.  James.  While  Dr.  Gibson  and  Mr.  James  explained  what 
users  would  like  to  do,  Mr.  Tenorio  developed  ideas  about  how  best  to  implement 
the  suggested  functions.  The  solution  outlined  here  is  believed  to  be  powerful 
but  simple;  it  does  not  introduce  sophistication  for  the  sake  of  sophistication.  It 
encourages  users  to  provide  ample  documentation  but  does  not  straightjacket  them 
with  excessive  requirements.  The  hope  here  is  that  new  users  would  soon  see  the 
usefulness  and  friendliness  of  the  software,  and  would  not  perceive  it  as  a  burden. 

7.2.1  The  Three  Proposed  Software  Components 
The  proposed  software  consists  of  three  components: 

1.  HISTORIAN:  a  text  management  system  based  on  CDC’s  UPDATE  product. 

2.  DATATRIEVE:  a  general-purpose  non-relational  database  product  provided 
by  Digital  Equipment  (available  on  the  PDL  VAX).2 

3.  A  driver  to  interface  between  the  user  on  the  one  hand,  and  HISTORIAN  and 
DATATRIEVE  on  the  other  hand.  This  driver  will  be  developed  as  part  of 
Phase  II  and  is  tentatively  called  FEMREC. 

Some  background  on  these  products  is  in  order  here. 

HISTORIAN  is  a  commercial  text  management  system  similar  to  CDC’s 
UPDATE  utility,  which  was  described  in  the  previous  section.  Most  engineers 
who  ever  used  CDC  or  Cray  computers  are  familiar  with  UPDATE.  The  two  main 
advantages  of  HISTORIAN  over  UPDATE  are  (1)  it  runs  on  all  major  computer 
types,  and  more  importantly,  and  (2)  it  relieves  users  of  the  burden  of  manual 
preparation  of  correction  sets.  This  second  feature  is  accomplished  by  means  of 

2  SMAKTSTAR  is  an  alternate  database  product  that  provides  essentially  the  same  functionality 
as  DATATRIEVE,  while  offering  some  minor  advantages.  DATATRIEVE  will  be  assumed  in  this 
section  with  the  understanding  that  SMAKTSTAR  or  some  other  product  may  be  substituted  in 
Phase  II. 
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a  utility  called  HISTGEN.  HISTGEN  allows  users  to  extract  a  source  file  from  a 
HISTORIAN  library  (version  n),  modify  this  file  using  a  screen  editor  (producing 
version  n  +  1),  and  then  automatically  generate  the  *  DELETE  and  *INSERT  cards 
(i.e.,  the  correction  set)  that  could  be  applied  to  version  n  to  produce  version  n  +  1. 
The  user  then  has  the  advantages  that  UPDATE  offers  in  terms  of  named,  reversible 
correction  sets,  and  at  the  same  time,  he  retains  the  flexibility  and  convenience  of 
a  screen  editor. 

Notwithstanding  these  advantages,  HISTORIAN  by  itself  is  inadequate  for  the 
problem  at  hand.  In  particular,  we  need  some  of  the  features  of  a  true  database.  In 
particular,  users  need  to  move  up  and  down  the  hierarchy  of  the  database,  issuing 
inquiry  commands  with  or  without  qualifiers  at  any  time.  They  need  to  extract, 
replace,  or  add  data  as  needed.  DATATRIEVE  provides  these  features,  but  would 
be  inadequate  by  itself  because  it  is  not  oriented  toward  storing  large  volumes  of  text 
data.  Hence  the  recommended  approach  takes  advantage  of  both  systems.  Driver 
code  (FEMREC)  interfaces  between  users,  HISTORIAN,  euad  DATATRIEVE.  This 
code  will  provide  a  convenient  and  friendly  screen-oriented  user  interface  with 
on-line  help,  selection  of  functions  from  menus,  and  prompts  for  information  that 
may  be  needed  when  new  data  is  entered.  The  provision  of  a  driver  makes  it  un¬ 
necessary  for  engineering  users  of  the  system  to  know  anything  about  HISTORIAN 
or  DATATRIEVE.  In  fact,  they  need  not  even  know  that  these  codes  are  being 
used.  This  is  not  only  true  for  users  who  extract  models  from  the  database,  but 
also  for  those  who  update  the  database.  Only  the  developers  of  FEMREC  (primar¬ 
ily  Mr.  Tenorio  of  ATA)  will  need  to  understand  these  products.  Having  written  a 
very  similar  code  recently,  Mr.  Tenorio  will  be  able  to  write  the  new  code  at  low 
cost  and  with  low  risk.  However,  the  software  will  be  easy  for  others  to  modify 
later  because  it  will  be  based  on  HISTORIAN  and  DATATRIEVE,  which  are  well 
documented  and  widely  used. 

It  should  be  noted  that  the  proposed  software  will  be  specific  to  VAX  computers. 
This  is  not  expected  to  be  a  problem  because  there  should  only  be  one  copy  of 
the  database,  maintained  on  a  particular  computer  at  FDL,  and  FDL  already  has 
VAXes  available  which  could  be  used  in  Phase  II.  There  should  not  be  any  need 
to  port  the  code  to  a  different  type  computer.  However,  before  any  commitments 
are  made  in  Phase  II,  this  issue  will  be  re-examined,  and  the  possibility  of  using  a 
database  product  other  than  DATATRIEVE  that  runs  on  more  than  one  machine 
type  will  be  investigated. 

Another  point  to  emphasize  is  that  the  only  purpose  of  this  software  is  to  store 
and  retrieve  models  and  information  about  those  models.  No  manipulation  of  the 
bulk  data  is  contemplated.  For  example,  we  would  not  attempt  to  check  the  bulk 
data  for  format  errors,  duplications,  etc.  Nor  would  we  attempt  to  operate  on  the 
data  in  any  manner,  such  as  merging  models,  redefining  node  points  in  terms  of 
different  coordinate  systems,  or  translating  models  between  COSMIC  and  MSC 
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format.  Where  such  software  aides  seem  appropriate,  they  will  be  left  to  separate 
codes,  which  are  discussed  in  Section  10. 

A  further  point  of  interest  is  that  with  the  exception  of  descriptor  records  which 
are  discussed  in  Sections  7.2.3  and  7.3.4,  there  is  nothing  about  this  database  that 
requires  the  use  of  NASTRAN.  That  is,  GIFTS  steering  files,  PATRAN  driver  files, 
or  input  to  many  other  codes  could  also  be  stored. 


7.2.2  Engineering  Considerations  Underlying  the  Proposed  Database 

The  design  of  the  proposed  database,  which  is  detailed  in  the  following  section,  is 
based  on  some  observations  about  the  kinds  of  models  that  will  be  mvolved,  the 
kinds  of  modifications  that  are  likely,  and  how  users  will  want  to  interrogate  the 
database  and  extract  data.  Some  discussion  of  these  assumptions  is  in  order  here. 

To  begin  with,  we  are  dealing  with  finite  element  models  of  aircraft.  Seldom 
if  ever  is  an  entire  aircraft  analyzed  in  a  one-shot  run  (i.e.,  without  benefit  of 
substructuring).  Thus  it  is  appropriate  to  take  as  our  primary  unit  of  information  a 
model  of  a  single  component  such  as  a  wing,  landing  gear,  horizontal  stabilizer,  etc. 
(However,  this  arrangement  does  not  preclude  the  possibility  of  storing  a  complete 
model  as  a  unit.)  Of  course,  interface  nodes  and  elements  will  appear  in  two  or  more 
component  models.  As  currently  envisioned,  there  will  be  no  attempt  to  reconcile 
interface  nodes  and  elements  when  two  or  more  components  are  joined  together. 
Other  software  may  be  developed  for  this  purpose  in  Phase  II. 

While  our  primary  unit  of  information  is  a  component,  means  must  be  provided 
to  accommodate  the  kinds  of  changes  that  users  might  desire.  Four  kinds  of  changes 
are  contemplated. 

First,  users  may  want  to  make  one-time  modifications  that  they  will  not  want  to 
save  in  the  database.  After  extracting  bulk  data,  the  user  could  make  such  changes 
easily,  using  a  familiar  text  editor.  If  after  running  NASTRAN,  however,  he  decides 
that  these  changes  ought  to  be  permanent,  this  can  be  done  at  that  time  using  one 
of  the  other  three  methods. 

Second,  users  may  simply  want  to  make  permanent  corrections  to  correct  errors 
or  obvious  shortcomings.  The  user  will  be  expected  to  validate  such  changes,  unless 
they  are  quite  trivial,  by  re-running  NASTRAN.  Although  the  changes  would  be 
expected  to  be  permanent,  the  provisions  of  HISTORIAN  will  make  it  possible  to 
undo  these  changes  should  the  need  arise.  When  entering  such  modifications  in 
the  database,  the  user  will  be  asked  for  a  short  explanation  of  the  change.  The 
user’s  name  along  with  the  current  date  and  time  will  be  entered  in  the  database. 
HISTORIAN  will  automatically  be  invoked  to  generate  and  save  a  correction  set. 

Third,  users  may  want  to  generate  a  new  version  of  a  component  which  is  sub¬ 
stantially  different  from  the  current  one.  Such  changes  could  arise  in  two  ways: 
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First,  there  could  be  a  new  version  of  the  component  which  is  physically  different 
from  the  current  one.  An  example  would  be  a  wing  whose  wing  box  is  made  out  of 
composites  instead  of  metal.  Second,  a  new  model  might  be  generated  or  acquired 
whose  purpose  is  different  from  the  original.  Thus,  a  simplified  version  of  an  existing 
stress  model  might  be  needed  for  dynamic  analysis  purposes,  and  would  be  much 
coarser  than  the  stress  model.  Since  these  models  both  reference  the  same  piece  of 
the  aircraft,  they  should  logically  carry  the  same  component  name,  and  should  be 
distinguished  by  a  version  identifier. 

Fourth,  users  may  which  to  generate  variations  on  a  basic  model.  The  differences 
between  these  modified  models  and  the  basic  model  would  be  minor  in  terms  of  the 
amount  of  data  that  is  actually  changed.  The  most  obvious  example  is  damage 
assessment,  where  the  model  is  repeatedly  modified  by  removing  or  changing  a  few 
elements  to  simulate  the  damage.  A  second  example  would  be  local  refinement  of 
the  model  in  a  certain  area  in  order  to  improve  stress  predictions.  Dozens  of  such 
variations  could  be  generated,  and  it  does  not  make  sense  to  generate  an  entire 
new  component  record,  with  its  accompanying  full  bulk  data  deck,  for  each  such 
variation.  The  approach  proposed  here  is  to  store  only  HISTORIAN  correction  sets 
for  these  variations,  not  a  whole  new  dataset.  This  gives  rise  to  another  database 
file  in  which  information  about  variations  is  stored,  along  with  pointers  to  another 
HISTORIAN  library  in  which  the  actual  correction  sets  are  stored. 

To  summarize,  we  have  defined  four  kinds  of  changes,  with  specific  terms  to 
describe  each: 

1.  One-time  changes  which  are  not  saved  in  the  database. 

2.  Error  corrections  which  are  expected  to  be  permanent. 

3.  New  versions  of  a  component  which,  while  they  still  represent  the  same  part 
of  an  aircraft,  are  substantially  different  either  physically  or  in  modeling  ap¬ 
proach.  Different  versions  of  the  same  component  are  identified  by  the  same 
component  name  but  different  version  names. 

4.  Variations  which  represent  small  changes  to  a  basic  component  that  represent 
model  refinements,  tradeoff  studies,  damage  tolerance,  etc. 

It  should  be  re-emphasized  that  in  none  of  these  cases  does  the  user  become 
involved  with  HISTORIAN  details  such  as  ^DELETE  and  ^INSERT  directives.  AH 
user  interaction  goes  through  FEMREC  which  handles  all  such  matters.  Also,  the 
distinctions  among  corrections,  new  versions  and  variations  are  somewhat  arbitrary, 
as  they  are  based  on  the  extensiveness  of  and  the  reasons  for  the  changes  that 
are  involved.  The  choice  would  be  entirely  up  to  the  user.  The  primary  payoff 
is  that  future  users  will  be  alerted  to  the  nature  of  the  differences  (extensive  or 
not).  A  minor  payoff  results  when  variations  are  used  in  terms  of  reduced  storage 
requirements. 
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As  the  next  section  shows,  the  database  files  will  include  various  descriptors 
that  will  aid  in  documenting  models  and  changes  to  models.  However,  it  is  very 
desirable  from  an  engineering  point  of  view  to  be  able  to  document  the  contents  of 
a  bulk  data  file  in  more  detail.  Users  often  do  this  by  means  of  comment  cards  in 
the  bulk  data  deck  itself.  However,  database  storage  of  these  comments  would  be 
more  useful  because  they  could  be  identified,  retrieved,  and  displayed  so  much  more 
easily  than  by  searching  with  a  text  editor  or  scanning  listings.  For  this  reason,  an 
additional  database  file  type  is  proposed  in  which  user  comments  are  stored  and 
are  referenced  back  to  individual  bulk  data  cards,  to  user-defined  card  sets,  or  to 
sets  that  are  recognized  by  NASTRAN  (loads  and  constraints).  In  cases  where 
existing  bulk  data  decks  already  have  comments  in  them,  it  may  be  advisable  to 
write  simple  software  that  would  retrieve  these  comments  and  present  them  to  the 
database  software  for  inclusion  in  the  database. 

7.2.3  Four  Kinds  of  Database  Files 

Our  database  file  will  thus  have  one  primary  file  per  component  (component  files). 
It  should  be  emphasized  that  these  records  will  not  store  the  actual  bulk  data,  only 
information  about  the  component  and  pointers  that  will  enable  FEMREC  to  direct 
HISTORIAN  to  extract  the  actual  bulk  data 

A  second  file  type,  correction  files,  will  contain  correction  sets  that  are  applied 
to  the  basic  model.  These  files  are  intended  to  store  correction  sets  that  constitute 
error  corrections,  in  contrast  with  the  variation  file  which  holds  changes  made  for 
engineering  reasons.  It  is  expected  that  the  corrections  stored  in  correction  files 
would  be  permanent,  but  they  would  be  stored  here  to  provide  traceability  and  the 
possibility  to  retract  corrections  should  the  need  arise. 

Third,  variation  files  will  contain  correction  sets  that  constitute  variations  on 
a  basic  component  model. 

Finally,  descriptor  files  will  be  used  to  document  bulk  data  cards,  as  discussed 
above.  For  example,  a  particular  MAT1  card  may  be  described  as  “Aluminum, 
T6065.”  A  PSHELL  card  may  be  described  as  “Upper  skin  thickness,  stations  49.125 
to  63. 5. r  A  set  of  GRID  cards  might  be  identified  as  “GRIDs  lying  on  spar  at 
station  101.25.”  A  set  of  elements  might  be  identified  as  “bulkhead  C-3.”  Finally, 
an  important  class  of  cards  that  need  to  be  identified  are  those  having  set  numbers 
selectable  through  the  case  control  deck.  The  two  primary  classes  of  this  type  are 
load  sets  and  constraint  sets  (of  which  there  are  two  kinds:  SPC  and  MPC).  Thus 
the  first  kind  of  documentation  records  would  be  those  that  refer  to  a  single  card, 
and  these  would  easily  be  identified  by  their  card  type  and  ID  (e  g.,  “MATl”  and 
“101”).  Second  would  be  sets  of  cards  which  would  be  identified  by  sets  of  ID’s  such 
as  elements  401,  403,  410-420,  and  429.  Third  would  be  load  sets  or  constraint  sets 
which  would  simply  be  identified  by  the  words  “loadset”  or  “SPCset”  or  “MPCset” 
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and  an  ID  number.  It  should  be  possible  to  provide  software  that  would  check  for 
additions,  deletions,  or  changes  to  members  of  these  sets  and  to  solicit  comments 
on  the  changes  for  inclusion  in  the  database. 

An  important  function  of  FEMREC  is  its  screen-oriented  interface  with  the 
user.  For  example,  users  could  see  a  list  of  available  components.  Having  picked  a 
component,  they  might  be  presented  with  lists  of  versions  or  variations.  They  could 
also  look  through  the  comments  that  document  a  particular  component.  They  could 
select  data  for  retrieval,  make  changes,  or  add  new  components  or  versions,  etc. 

Some  scenarios  that  illustrate  these  concepts  are  presented  in  Section  7.4. 


7.3  Layout  of  the  Proposed  Database 

This  section  presents  the  layout  of  the  database  as  presently  envisioned.  Four  files 
are  defined:  component  files,  correction  files,  variation  files,  and  descriptor  files. 
For  each  file,  descriptions  and  examples  are  given  for  each  data  item. 

While  this  arrangement  has  been  rather  carefully  thought  out,  it  would  of  course 
be  subject  to  revision  during  Phase  II  in  response  to  suggestions  by  FDL  engineers 
or  other  interested  parties.  Furthermore,  it  would  not  be  difficult  to  add  more  data 
elements  that  might  seem  advisable  as  experience  is  gained  in  Phase  II. 

The  descriptions  below  are  in  the  following  format: 

DATA  ELEMENT 

DESCRIPTION 

EXAMPLE(S) 

7.3.1  COMPONENT  Files 

This  database  file  serves  two  primary  purposes:  to  describe  a  model  and  to  point 
to  the  model  data  itself.  There  is  also  pointer  data  and  status  information.  There 
is  one  record  in  this  file  for  every  model  that  is  tracked.  The  following  records  Eire 
defined: 

SYSTEM 

Name  of  the  major  system  being  modeled 
F16 

COMPONENT-NAME 

Name  of  the  physical  component  being  modeled 
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STBD-WING 

VERSION-NAME 

Name  defining  a  particular  version  of  this  component 
Composite  wing  box 

COMPONENT-DESCRIPTION 

Brief  description  of  the  model  including  the  coarseness/fineness  of  the 
grid  selected,  the  elements  selected  and  the  boundary  conditions. 

P’ine  model  of  the  F-16  starboard  wing  (composite  wingbox) 
for  stress  analysis 

COMPONENT-AUTHOR 

Name  and  affiliation  of  the  original  model  author(s) 

McDonnell-Douglas  Corp.,  St.  Louis,  MO 
J.  A.  Smith,  R.  L.  Jones,  F.  W.  Johnson 


SOFTWARE 

Defines  the  finite  element  code  to  be  used 

COSMIC  NASTRAN,  MSC/NASTRAN,  GIFTS,  PATRAN 

DEVELOP-DATE 

Date  when  the  model  was  entered  into  the  database 
30Jun88 

ANALYSIS-CATEGORY 

Type  of  analysis  performed  by  this  model 

static,  dynamic,  aeroelastic,  heat  transfer 

HISTORIAN-NODE 

Name  of  the  DecNet  node  that  contains  the  required  library 
FDLVAX 

HISTORIAN-DIRECTORY 

Name  of  the  disk  and  directory  that  contains  the  library 
DISK$USER:  [FEMODELS] 
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HISTORIAN-FILE 

Name  of  the  data  file  that  contains  the  HISTORIAN  library 
F16.HIS 

HISTORIAN-DECK 

Name  of  the  deck  in  the  HISTORIAN  library  that  contains  the  input 
data  file 

WING 

RESULTS-COMMENTS 

Description  of  the  results  of  running  this  model 

Static  case  1  produces  5.26”  wing  tip  displ. 

REFERENCES 

Description  of  additional  reference  material 
General  Dynamics  report  82.1028A 


CORR-FLAG 

Indicates  if  modifications  have  been  made  to  the  basic  model 
Y/N 

VERSION-FLAG 

Indicates  if  there  axe  versions  of  the  component  model  in  the  database 
Y/N 

VARIATION-FLAG 

Indicates  if  there  are  variations  of  the  model  in  the  database 
Y/N 

7.3.2  CORRECTION  Files 

This  database  file  contains  the  data  elements  needed  to  briefly  describe  corrections 
that  have  been  made  to  a  basic  model.  Note  that  corrections  are  sequential,  and 
they  eire  backward  in  the  sense  that  they  would  take  an  existing  file  back  to  its 
previous  status. 


SYSTEM 
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Name  of  the  major  system  being  modeled  to  which  this  correction  set 
applies. 

F16 

COMPONENT-NAME 

Name  of  the  model  to  which  this  correction  set  applies 
Wing 

CORR-NAME 

Name  given  to  the  this  correction 
ELEM-FIX 

CORR-DESCRIPTION 

Brief  description  of  why  these  corrections  axe  being  made  as  well  as 
some  indication  of  the  ramifications  of  applying  or  not  applying  these 
changes 

QUAD4  elements  around  outboard  edge  of  flap  were  found  to 
have  interior  angles  approaching  180  degr. 

CORR-AUTHOR 

Full  name  of  the  Author 
G.  R.  Negaard 

CORR-DEVELOP  DATE 

Date  when  these  modifications  were  made 
30Jun88 

CORR  HISTORIAN  -FILE 

Name  of  the  data  file  that  contains  the  HISTORIAN  library 
F16MODS.HIS 

CORR-HISTORIAN-DECK 

Name  of  the  deck  in  the  HISTORIAN  library  that  contains  the  cor¬ 
rection  set  to  be  applied  to  the  basic  model 


MODS1 
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7.3.3  VARIATION  Files 

These  database  files  contain  data  elements  needed  to  briefly  describe  variations 
made  to  the  basic  model.  As  explained  in  the  previous  section,  a  variation  involves 
minor  changes  to  the  basic  model  and  is  hence  described  in  terms  of  a  correction 
set  which  references  the  original  model  data. 

SYSTEM 

Name  of  the  major  system  being  modeled  to  which  this  variation 
applies 

F16 

COMPONENT-NAME 

Name  of  the  model  on  which  this  variation  is  based 
STBD-WING 

VERSION-NAME 

Name  given  of  the  version  of  this  component  model 
Composite  wing  box 

VARIATION-NAME 

Name  given  to  the  new  VARIATION  of  the  basic  model 
STIFFER-STRINGER 

VARIATION-DESCRIPTION 

Brief  description  of  the  changes  made  to  the  basic  model 
Tried  stiffening  stringer  on  center  line 

VARIATION-AUTHOR 

Full  name  of  the  Author 

Lt  John  Jones,  AFWAL/FIBR 

VARIATION-DEVELOP-DATE 

Date  when  this  variation  of  the  model  was  developed 
30Jun88 


VARIATION-HISTORIAN-FILE 
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Name  of  the  data  file  that  contains  the  HISTORIAN  library 
F16VARIATI0NS.HIS 

VARIATION-HISTORIAN-DECK 

Name  of  the  deck  in  the  HISTORIAN  library  that  contains  the  cor¬ 
rection  set  to  be  applied  to  the  basic  model 

Wing-comp 

VARIATION-RESULTS 

Description  of  the  results  of  running  this  model 
Wing  tip  displacement  reduced  to  4.42” 

VARIATION-REFERENCES 

Description  of  additional  reference  material 
CSA  report  89.1026 

7.3.4  DESCRIPTOR  Files 

This  database  file  contains  data  elements  used  to  document  individual  cards  or  card 
sets  within  a  bulk  data  deck. 

SYSTEM 

Name  of  the  major  system  being  modeled  to  which  these  descriptors 
applies 

F16 

COMPONENT-NAME 

Name  of  the  model  to  which  these  descriptors  apply 
Wing 

VERSION  NAME 

Name  of  the  version  to  which  these  descriptors  apply 
Wing-22 

CARD-IDENTIFIER 


Name  of  the  card  or  card  set  to  which  these  comments  apply 

MAT1,  PSHELL,  GRID,  LOADSET,  SPCSET,  MPCSET 
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ID 


ID  number(s)  of  the  cards  being  described 
101,403,410-420 


COMMENTS 

Description  associated  with  the  set  of  cards  identified  by  the  CARD 
IDENTIFIER  and  ID 

Grids  for  spar  at  station  121.23 


7.4  Scenarios  for  Use  of  the  Database 

We  now  attempt  to  flush  out  the  descriptions  given  above  by  depicting  scenarios 
for  use  of  the  proposed  database.  The  intent  is  to  show  how  things  work  from  the 
user’s  point  of  view. 

Upon  entering  FEMREC,  the  user  would  see  a  top-level  menu  displayed  on  the 
screen.  Several  of  the  major  menu  items  are  described  briefly  in  the  following  text: 

7.4.1  Browsing  Through  the  Database 

Users  must  be  able  to  find  out  what  is  in  the  database.  One  might  simply  call  for 
a  list  of  all  models  currently  stored,  for  example.  Alternatively,  one  could  qualify 
the  search  by  asking  for  a  list  of  all  wing  models,  all  models  created  since  1985,  all 
models  that  use  composite  materials,  etc.  Having  picked  a  particular  component, 
further  browsing  functions  would  be  made  available  by  a  second-level  menu.  One 
could  ask  for  a  list  of  all  the  variations  of  a  particular  component,  for  example,  one 
could  display  all  descriptors  records  (see  7.3.4)  that  refer  to  material  cards. 

7.4.2  Adding  a  New  Component  Model 

An  engineer  who  has  received  a  new  model  will  presumably  spend  some  time  study¬ 
ing  it  and  making  NASTRAN  runs.  At  some  point,  he  will  be  ready  to  enter  the 
model  into  the  database.  The  Center  should  establish  standards  that  models  would 
have  to  meet  before  they  qualify  for  entry  in  the  database,  and  users  should  get 
approval  from  the  director  of  the  Center  before  entering  a  new  model.  Alternatively, 
unproven  models  could  be  entered  for  test  purposes  if  they  were  clearly  marked  as 
such. 

The  engineer  would  pick  the  top-level  function  called  “enter  new  model.”  He 
would  then  be  prompted  for  information  about  the  model,  as  indicated  in  Section 
7.3.1  above.  He  would  then  be  asked  if  he  wanted  to  enter  information  about 
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individual  cards  or  card  sets  in  the  bulk  data.  Such  information  would  not  be 
mandatory,  but  just  asking  for  it  at  this  point  would  encourage  users  to  provide  this 
kind  of  valuable  information.  Thus,  referring  to  listings  and  plots,  the  user  could 
enter  information  about  grid  point  and  element  locations,  thicknesses,  material 
properties,  load  sets,  and  constraint  sets.  In  each  case,  up  to  about  200  characters 
of  descriptive  text  could  be  entered,  and  this  text  could  be  referred  to  a  single  card, 
to  cards  sets  recognized  by  NASTRAN  (load  and  constraint  sets),  and  to  arbitrary 
card  sets  (such  as  lists  of  elements). 

7.4.3  Adding  or  Revising  Descriptive  Material 

It  is  unlikely  that  a  user  could  or  would  want  to  enter  all  descriptive  material  at  a 
single  sitting.  Thus,  another  top-level  menu  item  would  enable  revision  or  addition 
of  descriptive  material  for  a  model.  This  would  be  particularly  useful  in  the  case 
of  bulk  data  descriptions,  which  could  run  to  hundreds  of  hnes  of  text.  Note  that 
revision  or  addition  of  descriptive  material  would  not  constitute  modification  of  a 
model,  as  tagged  by  “CORR-FLAG”  in  7.3.1.  Only  changes  to  the  bulk  data  itself 
constitute  a  modification. 

7.4.4  Variations  and  Corrections 

In  the  preceding  discussion,  we  distinguished  between  a  “variation”  and  a  “correc¬ 
tion.”  Although  the  user  would  be  free  to  classify  a  particular  change  as  either  a 
variation  or  a  correction,  the  intent  is  that  corrections  would  fix  clear  errors  or  short¬ 
comings  .  and  would  be  expected  to  be  permanent  (subject  to  revocation,  however; 
see  7.2.2).  Variations  would  be  intended  for  changes  such  as 

1.  Strengthening  a  particular  area  of  a  structure; 

2.  Introducing  more  refinement  into  a  region  subject  to  stress  concentrations; 

3.  Changing  element  types  (e.g.,  QUAD4  instead,  of  SHEAR  elements;  BAR 
instead  of  ROD); 

4.  Removal  or  alteration  of  some  elements  as  part  of  a  damage  tolerance  study. 

Some  of  these  changes  might  appear  to  be  candidates  for  permanent  modifications. 
For  example,  if  refinement  of  a  model  did  mdeed  provide  better  stress  predictions, 
one  might  be  tempted  to  discard  the  old  model  and  retain  only  the  refined  model. 
This  would  probably  not  be  wise  because  future  users  of  the  database  could  benefit 
from  seeing  how  this  refinement  improved  the  results. 

Some  bulk  data  cards  are  grouped  in  sets  by  NASTRAN  (loads  and  constraints). 
Thus  new  load  sets  or  constraint  sets  could  be  added  without  disturbing  the  old 
ones,  so  that  these  cases  might  best  be  handled  as  corrections  rather  than  variations. 
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7.4.5  Extraction  of  Bulk  Data 

Having  picked  a  particular  component  model  and  perhaps  a  particular  version 
and/or  variation  thereof,  the  user  may  want  to  extract  the  bulk  data.  Another 
menu  item  would  be  provided  for  this  purpose.  The  bulk  data  file  could  then  be 
edited  by  the  user  before  being  submitted  to  NASTRAN.  If  the  results  were  satis¬ 
factory,  the  user  might  wish  to  enter  the  edited  file  in  the  database  either  as  a  new 
component  (if  the  changes  were  extensive),  as  a  correction  (if  the  changes  consti¬ 
tuted  error  corrections),  or  as  a  variation  (if  the  changes  were  limited  in  scope,  and 
were  not  intended  to  replace  the  basic  model).  In  the  case  of  variations  or  correc¬ 
tions,  HISTORIAN  would  automatically  generate  the  correction  set,  and  FEMREC 
would  store  it  in  the  database. 


7.4.0  Deletions 

N 

Finally,  there  would  be  a  function  to  delete  a  variation  or  a  correction.  Also,  if  a 
variation  proved  to  be  quite  extensive,  a  user  might  decide  it  ought  to  be  classified 
as  a  new  component  rather  than  a  variation.  This  could  be  accomplished  simply  by 
extracting  the  bulk  data,  deleting  the  variation,  and  submitting  the  bulk  data  as  a 
new  component  model. 


7.5  Operations  Automatically  Carried  Out  by  FEMREC 

This  section  briefly  describes  the  operations  that  would  be  carried  out  by  FEMREC 
in  response  to  the  various  kinds  of  user  actions.  Users  would  not  have  to  anything 
about  these  matters;  they  are  included  here  only  to  show  how  the  proposed  system 
would  work. 

The  basic  organization  is  shown  in  Figure  7.  Note  that  all  user  interaction  takes 
place  through  FEMREC,  which  displays  information  one  screen  at  a  time,  with 
user  input  prompted  by  menu  displays.  There  is  no  direct  user  interaction  with 
DATATRIEYE  or  HISTORIAN. 

Figure  8  shows  the  actions  that  take  place  when  a  new  component  model  is 
added.  In  response  to  user  commands,  FEMREC  generates  a  command  file  which 
causes  HISTORIAN  to  read  a  small  directive  file  along  with  the  user  bulk  data  and 
then  add  the  bulk  data  to  its  bulk  data  library  file.  Figure  9  shows  what  happens 
when  the  user  requests  extraction  of  a  bulk  data  file  for  a  particular  component 
model.  In  this  case  the  HISTORIAN  directive  file  causes  it  to  access  its  bulk  data 
library  file  and  write  the  requested  bulk  data  on  a  file.  Figure  10  shows  the  same 
operation  except  with  a  variation  requested.  In  this  case  HISTORIAN  first  accesses 
the  library  in  which  it  stores  one  correction  set  corresponding  to  each  variation. 
The  proper  set  is  extracted  and  submitted  to  HISTORIAN  which  now  references 
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Figure  7.  Basic  database  organization 
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Figure  8.  Adding  a  new  component  model 
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Figure  10.  Extracting  bulk  data  with,  a  variation 
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its  bulk  data  library,  extracts  and  modifies  the  proper  data,  and  writes  it  to  a  file 
for  the  user.  Figure  11  shows  a  user  creating  a  new  variation  of  a  component  model. 
Previously,  he  had  extracted  the  bulk  data  he  wanted  and  then  had  modified  it  with 
a  text  editor.  HISTORIAN  is  asked  to  compare  the  modified  bulk  data  with  the  old 
bulk  data,  generate  a  correction  set  that  could  be  used  generate  the  new  data  from 
the  old,  and  then  store  the  correction  set  in  its  variation  library.  Finally,  Figure  12 
shows  the  process  that  is  used  to  add  a  new  correction  to  a  component  model.  As 
with  variations,  HISTORIAN  is  called  to  generate  a  correction  set.  This  correction 
set  is  then  combined  with  each  variation  correction  set  (if  any  exist)  to  see  whether 
any  conflicts  exist.  Assuming  no  conflicts  exist,  HISTORIAN  is  called  once  more, 
this  time  to  generate  a  backward  correction  set,  i.e.,  one  that  generates  the  old  file 
from  the  new.  This  correction  set  is  then  stored  in  the  “corrections”  database.  The 
reason  for  this  approach  is  that  we  want  to  store  the  revised  bulk  data,  not  the 
original.  Recall  that  corrections  are  expected  to  be  “semi-permanent.” 

7.6  Security 

As  discussed  in  Section  2,  security  will  be  an  important  concern.  The  models  col¬ 
lected  by  the  Center  will  be  very  valuable  to  the  Air  Force  and  must  be  safeguarded 
appropriately.  On  the  other  hand,  the  Center  will  only  be  useful  if  information 
about  models  becomes  widely  known  in  the  Air  Force,  and  perhaps  in  contrac¬ 
tor  organizations  as  well.  The  HISTORIAN/DATATRIEVE  approach  provides  a 
natural  solution  to  these  seemingly  contradictory  requirements.  This  is  because 
descriptive  information  is  kept  in  one  set  of  files  (DATATRIEVE  database  files), 
while  the  actual  bulk  data  is  kept  in  HISTORIAN  library  files.  Thus  the 
HISTORIAN  library  files  could  be  kept  secure  while  the  database  files  would  be 
freely  available.  The  HISTORIAN  files  could  be  kept  on  tape  cartridges  which 
could  be  kept  under  lock.  The  database  pointers  that  locate  HISTORIAN  files  in 
terms  of  directory  name  and  file  name  could  be  modified  to  refer  to  a  tape  cartridge. 

A  tempest  version  of  the  Micro  VAX  computer  has  recently  been  announced. 
When  the  Center  is  ready  to  begin  full  operations,  acquisition  of  such  a  system  will 
be  considered. 


7.7  Summary 

This  section  has  described  the  logistical  problems  encountered  in  documenting  and 
maintaining  finite  element  models,  and  has  proposed  a  rather  specific  solution  in 
terms  of  available  software.  It  is  our  belief  that  this  solution  will  provide  an  effective 
tool  for  use  in  the  proposed  Center.  All  the  software  should  be  ready  for  use  within 
a  few  weeks  after  Phase  II  begins.  This  will  leave  time  to  gain  experience  with  five 
model  data  and  to  refine  the  system  in  the  process.  Also,  it  would  be  easy  to  add 
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Figure  11.  Creating  a  new  variation 
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Figure  12.  Making  a  correction 
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Figure  12.  Making  a  correction  (Continued) 
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new  data  items  to  those  listed  above. 

Some  unresolved  issues  remain  in  this  plan.  For  example,  when  bulk  data  de¬ 
scriptions  are  entered,  it  would  be  desirable  to  ensure  that  the  referenced  caxd(s) 
actually  exist.  Also,  when  changes  are  made,  it  would  be  desirable  to  delete 
descriptions  of  cards  that  are  deleted.  These  issues  could  easily  be  handled  by 
some  auxiliary  software  that  could  be  invoked  by  the  command  files  generated  by 
FEMREC. 

Also,  we  have  not  said  whether  executive  control  and  case  control  decks  would 
be  stored,  and  if  so,  whether  they  would  be  attached  to  bulk  data  decks  or  stored 
separately.  Arguments  can  be  made  either  way.  This  issue  will  be  addressed  in 
Phase  II. 

7.8  Other  Database  Approaches 

There  are  of  course  other  solutions  to  the  problems  addressed  in  this  section.  We 
briefly  mention  three  of  them  along  with  the  reasons  why  the  first  two  were  consid¬ 
ered  unsatisfactory.  Again,  these  decisions  are  subject  to  revision  if  new  information 
becomes  available  in  Phase  II.  Insufficient  information  is  available  at  this  time  to 
pass  judgement  on  the  third  option,  CDMS. 

7.8.1  Other  Commercial  Database  Products 

First,  many  commercial  database  products  Eire  available  that  do  an  excellent  job 
with  certain  kinds  of  information.  However,  these  products  sire  not  generally  well 
suited  for  large  ASCII  text  files,  which  is  what  a  bulk  data  deck  is,  in  essence.  The 
UPDATE/HISTORIAN  approach,  although  based  on  20-year-old  technology,  still 
provides  the  best  solution,  when  augmented  by  a  database  code  such  as 
DATATRIEVE  and  a  driver  code  which  we  call  FEMREC. 


7.8.2  MacNeal-Schwendler’s  New  Database 

Second,  MacNeal-Schwendler  Corporation  is  making  a  considerable  investment  in 
a  new  executive  system  and  a  new  internal  database  for  MSC/NASTRAN.  This 
database  will  replace  the  database  which  was  introduced  along  with  superelements 
about  10  years  ago.  The  new  database  comes  with  a  data  definition  language 
that  sophisticated  users  can  use  to  define  relations  among  data  items  down  to  the 
level  of  individual  fields  on  bulk  data  cards.  Initially,  the  main  use  for  this  database 
scheme  will  be  to  provide  efficient  restarts.  But  the  generality  of  the  MSC  approach 
suggests  the  tempting  possibility  of  using  it  to  document  models.  However,  the  MSC 
database  includes  several  drawbacks  for  our  purposes.  First,  it  is  a  proprietary 
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product.  Second,  it  will  probably  not  be  released  before  the  end  of  1988.  Third, 
information  available  at  present  is  somewhat  sketchy,  making  it  difficult  to  make 
projections  about  using  it. 


7.8.3  Configuration  Data  Management  System 

A  system  called  the  Configuration  Data  Management  System  (Ref.  [7])  has  been 
developed  for  the  Aeromechanics  Branch  of  FDL.  This  system  performs  data  man¬ 
agement,  pre-processing,  and  post-processing  functions  for  users  of  ten  different 
aerodynamics  codes.  Users  of  CDMS  may  generate  geometric  models,  create  in¬ 
put  files  for  any  of  the  codes,  initiate  execution  of  a  code,  retrieve  and  manipulate 
output,  and  pass  data  downstream  to  other  codes.  All  this  is  handled  by  an  exec¬ 
utive  driven  by  commands  or  menu  picks.  The  potential  for  applying  a  modified 
version  of  CDMS  (or  a  system  patterned  after  CDMS)  to  finite  element  analysis  is 
intriguing. 

The  geometry  processor  in  CDMS  is  called  I3G.  It  performs  six  major  functions: 
surface  manipulation,  surface  grid-point  generation,  display  functions,  database  op¬ 
erations,  and  output  functions.  The  surface  generation  functions  axe  kept  simple 
in  recognition  of  the  fact  that  CAD  systems  do  this  better.  Instead,  an  interface  is 
provided  to  access  CAD  data.  I3G  requires  geometric  data  in  IGES  format.  Inter¬ 
face  codes  have  been  written  to  convert  data  from  severed  geometry  sources  which 
do  not  use  IGES  format. 

It  should  be  recognized  that  the  geometric  data  required  for  aerodynamic  analy¬ 
sis  is  somewhat  different  from  the  geometric  data  required  for  finite  element  analysis. 
Aerodynamic  analysis  is  concerned  solely  with  surfaces,  whereas  finite  element  struc¬ 
tured  analysis  is  concerned  with  line  elements,  surface  elements,  and  solid  regions. 
Even  if  we  focus  attention  solely  on  surface  elements,  we  find  detedls  such  as  stiff¬ 
eners  and  cutouts  that  do  not  appear  in  aerodynamic  anedysis.  There  is  also  data 
like  thicknesses  and  material  properties  that  has  no  direct  parallel  in  aerodynamic 
anedysis. 

It  certednly  ought  to  be  possible  to  modify  I3G  to  handle  finite  element  data. 
However,  such  an  effort  would  likely  end  up  reinventing  the  finite  element  mesh 
generator,  and  there  eue  already  enough  of  those  around.  It  thus  appears  that  I3G 
or  an  extension  thereof  would  not  be  suitable  for  finite  element  data.  This  conclusion 
is  based  on  a  review  of  the  CDMS  fined  report  (Ref.  [7])  which  does  not  go  into  detail 
about  data  formats.  Further  investigation  in  Phase  II  could  conceivably  reverse  this 
conclusion. 

The  job  submitted  and  output  retrieved  functions  of  CDMS  do  not  seem  par¬ 
ticularly  attreictive  for  finite  element  programs  either.  Only  one  or  two  analy¬ 
sis  programs  (NASTRAN  and  possibly  ASTROS)  would  be  used  by  users  of  the 
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proposed  database,  and  procedures  for  running  these  codes,  interfacing  them  to 
pre-  and  post-processors,  etc.,  axe  already  well  developed. 

This  leaves  the  possibility  of  using  CDMS’  data  management  facility.  Not 
enough  is  said  about  the  details  of  this  facility  in  the  Final  Report  to  draw  a 
conclusion.  The  usefulness  of  the  CDMS/Oracle  approach  would  depend  largely  on 
the  ability  to  tailor  it  to  the  specific  needs  of  finite  element  analysis,  and  on  its 
ability  to  store  supporting  documentation  along  with  the  data  itself.  Oracle  is  a 
very  expensive  commercial  product.  It  would  likely  not  be  cost-effective  to  procure 
a  separate  Oracle  license  for  the  Model  Center;  an  existing  installation  would  have 
to  be  used  instead. 

In  short,  CDMS  does  not  presently  seem  attractive  for  storage  and  manipulation 
of  finite  element  data.  Again,  this  conclusion  is  based  on  a  cursory  understanding 
gained  from  the  Final  Report  and  is  subject  to  review  in  phase  II. 

7.8.4  Other  Database  Software 

One  other  database  possibilities  is  CADDB,  the  database  that  accompanies  the 
CADS  graphics  software.  An  advantage  of  this  approach  is  its  availability  within 
FDL.  CADDB  would  have  to  be  modified  to  provide  a  means  for  storing  identifying 
information.  This  possibility  will  be  investigated.  Another  candidate  is  RIM,  which 
is  available  on  the  FDL  VAX,  with  a  smaller  version  available  on  PC’s.  Again  the 
question  is  whether  RIM  would  be  suitable  for  storing  identifying  information. 
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The  statement  of  work  includes  the  sentence,  “The  study  would  also  address  prob¬ 
lems  associated  with  different  models  of  the  same  system  that  have  varying 
degrees  of  refinement.”  This  section  discusses  these  problems  from  several  points  of 
view.  First  is  a  discussion  of  how  one  compares  results  from  such  models,  for  both 
dynamic  and  static  cases.  This  is  followed  by  a  section  on  convergence  of  results  as 
models  are  refined,  and  the  practice  of  “smearing.”  There  are  discussions  of  three 
related  topics:  reduced-order  modeling,  model  tuning,  and  meta-models. 

The  intent  of  this  section  is  simply  to  review  these  topics,  pointing  out  directions 
that  could  be  followed  in  a  further  investigation  of  this  topic. 


8.1  Equivalence  of  Dynamic  Models 

Dynamic  models  require  much  less  detail  than  static  models  as  a  rule,  because  static 
stresses  require  local  modeling  accuracy  whereas  natural  frequencies  and  modes 
shapes  are  generally  properties  of  the  structure  as  a  whole,  and  are  only  mildly 
sensitive  to  local  modeling  detail.  Natural  frequencies  are  the  easiest  result  to 
check  when  comparing  two  models  having  different  degrees  of  refinement.  These 
numbers  can  be  misleading,  however,  unless  the  analyst  can  assure  himself  that 
they  represent  the  same  mode  shape.  Mode  shapes  may  be  compared  in  terms  of 
node  points  that  appear  in  both  models.  Mode  shapes  from  both  models  may  be 
reduced  to  this  set  of  node  points  for  the  comparison.  Qualitative  comparisons  can 
be  made  by  means  of  graphical  displays  (preferably  animated). 

Assuming  such  displays  have  given  evidence  that  the  mode  shapes  appear  roughly 
similar,  a  numerical  evaluation  can  be  made  by  computing  the  normalized  scalar 
product  of  the  two  mode  shapes.  A  value  close  to  unity  indicates  good  comparison. 
A  more  elaborate  check  involves  the  computation  of  revised  pseudo-modal  mass 
matrices,  i.e.,  $TM$',  where  $  and  are  the  mode  shapes  being  compared, 
and  M  is  the  mass  matrix,  reduced  to  the  comparison  degrees  of  freedom.  This 
calculation  provides  cross-orthogonality  checks  as  well. 

These  methods  also  apply  to  comparison  of  analytical  results  to  test  results. 


8.2  Equivalence  of  Static  Models 

Static  models  are  generally  intended  for  stress  predictions.  However,  in  some  cases 
analysts  may  be  concerned  only  with  static  displacements.  Displacements,  like 
mode  shapes,  are  less  sensitive  to  local  details  as  a  rule,  so  that  coarse  models  may 
be  compared  with  fine  models  much  the  same  as  in  dynamic  cases. 

Where  stresses  are  of  interest,  analysts  generally  need  as  much  refinement  as 
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they  can  afford.  However,  there  is  one  way  in  which  coarse  models  can  be  used  to 
advantage  in  stress  analysis.  Assume  that  attention  is  to  be  focused  on  stresses  in 
a  particular  area  of  the  structure.  One  can  start  with  a  coarse  model  and  compute 
static  deformations  and  node-point  forces.  Then,  the  area  of  interest  can  be  isolated 
and  modeled  in  detail.  Two  approaches  are  possible:  one  can  either  prescribe 
the  displacements  from  the  coarse  model  on  the  boundaries  of  the  fine  model,  or 
prescribe  the  node-point  forces  on  the  boundary,  leaving  the  displacements  free. 
For  statically  determinate  structures,  the  latter  method  is  exact  and  the  former 
method  is  poor.  For  a  structure  having  stiff  load  paths  parallel  to  the  section  being 
modeled,  prescribed  displacements  may  be  more  accurate.  Since  neither  extreme 
case  generally  holds  in  practice,  either  method  must  be  used  with  some  caution. 
In  using  such  an  approach  in  an  optimization  study,  for  example,  it  would  be  wise 
to  rerun  the  coarse  model  periodically,  using  the  revised  properties.  A  new  set  of 
boundary  forces  or  displacements  would  then  be  obtained  for  application  to  the  fine 
local  model.  These  issues  are  discussed  in  some  detail  in  Ref.  [8],  which  presents  a 
combined  method  in  addition  to  the  force  and  displacement  methods. 


8.3  Convergence  with  Mesh  Refinement 

University  courses  in  finite  element  analysis,  if  they  discuss  theory  in  any  depth  at 
all,  treat  the  problem  of  convergence  of  finite  element  models.  The  issue  is  usually 
discussed  in  the  context  of  a  simple  model  like  a  flat  plate.  A  theorem  is  proven 
which  states  something  like  the  following: 

If  the  model  is  refined  in  a  systematic  way  (such  that  each  refinement 
includes  all  the  node  points  of  its  predecessor),  and  if  the  finite  elements 
satisfy  the  conditions  of  completeness  and  continuity,  then  the  approxi¬ 
mate  solution  produced  by  the  model  approaches  the  exact  solution  in 
the  limit  as  the  mesh  density  increases  without  bound.  For  elements  for¬ 
mulated  with  displacements  as  independent  variables,  the  convergence 
is  monotonic  from  the  stiff  side. 

The  theorem  may  be  illustrated  by  actually  running  models  with  increasing  refine¬ 
ment. 

The  student  may  come  away  with  a  great  deal  of  concern  for  questions  of  con¬ 
vergence  and  accuracy.  However,  if  he  begins  applying  finite  element  methods  in 
industry,  he  finds  little  or  no  opportunity  to  deal  with  such  questions.  For  one  thing, 
such  concerns  tend  to  be  crowded  out  by  schedule  and  budget  problems.  Also,  real 
structures  are  usually  complicated  by  cutouts,  thickness  changes,  stiffeners,  attach¬ 
ments,  etc.  The  analyst’s  “budget”  may  be  used  up  just  in  placing  node  points  at 
all  the  comers,  thickness  changes,  etc.  This  leaves  no  opportunity  for  experimenting 
with  refinement  of  the  mesh. 
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8.4  Smearing 

In  some  cases,  parts  of  structures  are  so  complex  that  the  “budget”  of  node  points 
would  be  exceeded  if  all  the  details  were  modeled  with  distinct  elements.  In  this  case, 
“smearing”  is  a  common  technique  by  which  equivalent  simple  elements  are  used  to 
model  a  geometrically  complex  portion  of  a  structure.  For  example,  a  stiffened  plate 
may  be  modeled  by  an  equivalent  homogeneous  plate  having  orthotropic  material 
properties.  If  properly  devised,  an  equivalent  model  provides  the  same  stiffness 
and  inertia  properties  as  a  refined  model,  in  the  modes  of  deformation  which  axe 
important  for  the  particular  loading  being  applied. 

In  practice,  however,  smearing  is  generally  done  with  simple  rules  of  thumb 
which  may  or  may  not  provide  good  results.  For  example,  when  a  uniform  plate 
is  used  to  represent  a  plate  with  a  hole,  one  could  just  average  the  thickness  over 
the  area  of  the  plate.  But  if  the  plate  vibrates  in  its  first  mode,  and  if  the  uniform 
plate  predicts  that  much  of  the  strain  energy  for  that  mode  is  in  the  area  where  the 
hole  is,  then  this  “equivalent”  plate  may  in  fact  be  much  too  stiff. 


8.5  Model  Tuning 

Model  timing  refers  to  the  systematic  adjustment  of  selected  parameters  in  a  finite 
element  model  in  order  to  bring  the  model  into  closer  agreement  with  reference 
values  which  Eire  considered  correct.  Usually,  these  reference  values  axe  laboratory 
test  results.  The  premise  is  that  some  of  the  model  parameters,  such  as  joint 
stiffnesses  or  bearing  stiffnesses,  axe  uncertain,  and  that  by  matching  selected  test 
results,  better  values  can  be  obtained  for  these  uncertain  parameters.  This  process 
may  be  carried  out  by  optimization  software  such  as  ADS/NASOPT  or  ASTROS. 

Suppose,  for  example,  one  wanted  to  time  the  first  three  frequencies  to  match 
test  data.  Then  the  following  optimization  problem  could  be  posed: 

Minimize  W(X) 

subject  to  0.98u>f  <  <  1.02a;?’  ,  i  =  1 . . .  3 

where  a \  is  the  itn  natural  frequency,  and  a )J  is  the  corresponding  test  value.  X 
is  a  vector  of  “design  variables”  (in  this  case,  the  uncertain  model  parameters)  and 
W (X)  is  a  dummy  objective  function.  The  objective  function  is  immaterial  because 
the  initial  design  would  be  “infeasible,”  i.e.,  the  constraints  would  be  violated.  The 
optimizer  would  ignore  the  objective  function  until  it  was  able  to  find  a  “feasible” 
design,  i.e.,  one  for  which  all  three  computed  natural  frequencies  axe  within  2%  of 
the  corresponding  test  values.  At  this  point  the  optimization  would  be  terminated. 

The  same  procedure  could  be  applied  in  reduced-order  modeling.  That  is, 
assume  a  complex  model  of  a  given  structure  exists,  and  the  goal  is  to  create  a 
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simpler  model  which  matches  the  complex  model  in  certain  respects.  That  is,  one 
might  wish  to  reproduce  the  first  few  natural  frequencies  closely,  or  predict  the  same 
general  displacements  under  a  given  load.3  The  coarse  model  could  then  be  run  for 
a  few  cycles  through  an  optimizer  in  order  to  refine  its  element  properties. 


8.6  Reduced-order  Modeling 

The  subject  of  reduced-order  modeling  is  related  to  the  topic  at  hand.  Reduced- 
order  modeling  refers  to  the  systematic  generation  of  simplified  models  of  structural 
systems,  and  is  usually  addressed  in  the  context  of  analysis  and  design  of  struc¬ 
tures  having  feedback  control  devices.  For  example,  Lamberson  in  Ref.  [9]  develops 
a  plate  finite  element  to  represent  complex  truss  lattices  and  compares  both  the 
static  deformations  and  dynamic  mode  shapes.  He  further  shows  that  feedback 
controllers  designed  using  the  simplified  model  perform  as  well  as  those  designed 
with  detailed  truss  models.  References  [10]  and  [11]  describe  similar  studies,  while 
Ref.  [12]  discusses  a  reduced-order  model  used  in  an  optimization  study. 


8.7  Met  a- mo  dels 

Pre-processing  codes  for  finite  element  programs  have  existed  for  many  years.  Most 
of  these  axe  graphics-oriented.  As  a  rule,  models  may  be  generated  either  by  spec¬ 
ifying  individual  grids  and  elements  or  by  defining  regions  (“patches,”  “grids”), 
and  having  the  software  fill  in  the  regions  with  meshes  of  a  specified  density.  The 
definition  of  a  model  in  terms  of  these  regions  may  be  called  a  “meta-model.” 

An  example  of  this  process  may  be  seen  in  Figure  13.  In  the  upper  left-hand 
comer  is  a  plot  of  a  meta-model  for  a  simple  piece  of  structure,  having  an  offset  hole 
and  surrounding  stiffeners.  This  meta-model  was  generated  by  a  GIFTS  command 
file  of  about  twenty  lines.  By  simple  modifications  to  this  file,  models  of  varying 
degrees  of  fineness  may  be  generated,  as  seen  in  the  other  plots. 

Currently  many  finite  element  models  are  generated  using  pre-processors  such 
as  PATRAN  or  GIFTS,  or  via  interfaces  from  CAD/CAM  programs.  Unfortunately 
none  of  these  methods  can  be  called  an  industry  standard.  Thus  it  does  not  seem 
reasonable  to  include  a  standard  meta-model  format  in  the  proposed  military  spec¬ 
ification  (Section  6).  However,  there  is  no  reason  why  meta-models  should  not  be 
delivered,  even  if  they  are  only  stored  and  never  exercised  by  the  proposed  Center. 


3One  could  not  expect  to  reproduce  stresses  well,  however,  since  these  depend  so  strongly  on 
local  modeling  details. 
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Figure  13.  Generating  models  of  various  densities  from  a  meta-model 
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9.  Relationship  to  Other  Programs 

Two  major  Air  Force  logistics  programs  axe  presently  investigating  the  integration 
of  design,  manufacturing,  and  logistics  data.  These  programs  involve  the  manage¬ 
ment  of  large  amounts  of  technical  data,  and  include  the  potential  for  using  and 
transmitting  finite  element  models  on  a  broad  scale.  During  Phase  II,  progress  on 
these  programs  will  be  monitored  to  see  how  they  might  impact  a  finite  element 
model  center,  both  in  the  short  and  long  term.  It  is  possible  that  a  synergistic 
relationship  can  be  established. 

9.1  Computer-aided  Aquisition  and  Logistics  Support 

CALS  (Computer-aided  Aquisition  and  Logistics  Support)  is  primarily  concerned 
with  the  repair  and  maintenance  (R&M)  functions  of  the  Air  Force  Logistics  Com¬ 
mand.  These  functions  involve  some  data  that  is  either  directly  or  indirectly  related 
to  structural  analysis. 

The  broad  goals  of  the  program  are: 

•  Bridge  “islands  of  automation”  in  DoD  and  industry  design  and  logistics  pro¬ 
cesses. 

•  Gain  the  benefits  of  a  highly  automated  and  integrated  system 

—  Reduce  paper 

—  Improve  the  timeliness  and  accuracy  of  information 
—  Design  more  supportable  weapons  systems 
—  Reduce  costs 

A  wide  variety  of  data  is  expected  to  be  encompassed  by  CALS,  including  tech¬ 
nical  publications  such  as  standards  and  technical  manuals,  engineering  drawings, 
and  CAD/CAE  databases.  No  specific  mention  of  finite  element  models  has  been 
found  in  CALS  publications,  however. 

The  specified  functional  requirements  of  the  system  are 

•  Development  of  an  integrated  design,  manufacturing,  and  logistics  database 
to  provide 

—  Near  real-time  configuration  updates 
—  Specified  government  access 
—  Database  transportability 


9.2  Integrated  Design  Support  System 


73 


•  Use  of  online  R&M  design  tools  in  a  CAD/CAE  integrated  environment 

•  Automated  generation  of  logistics  data  products  such  as  tech  manuals  and 
engineering  drawings. 


9.2  Integrated  Design  Support  System 

IDS  (Integrated  Design  Support  System)  is  designed  to  provide  direct  engineering 
support  for  maintenance,  modification,  and  repair  of  Air  Force  Weapons  systems. 
The  IDS  goal  is  to  develop  a  computer  software  system  to  manage  technical  data 
across  the  life  cycle  of  a  system.  IDS  is  similar  to  CALS  in  requiring  the  capture  of 
data  from  design,  manufacturing,  and  logistics.  It  differs  in  scope  (Air  Force  only), 
and  in  the  emphasis  of  the  program.  IDS  is  more  technically  oriented,  with  data 
ranging  from  engineering  drawings  through  structural  and  aerodynamic  analysis 
data,  to  process  plans  and  fabrication  techniques,  and  concludes  with  tech  order 
maintenance  and  repair  data. 

As  an  integral  part  of  IDS,  it  is  envisioned  that  finite  element  models  will  be 
available  from  contractors  on  call  and  can  be  transmitted  electronically  when  needed 
for  analysis.  While  model  delivery  is  still  in  the  future,  this  aspect  of  IDS  will  be 
monitored  closely,  since  it  bears  directly  on  the  mission  of  the  proposed  Model 
Center. 
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10.  Phase  II  Operation 

This  section  outlines  plans  for  Phase  II  of  this  SBIR.  The  formal  Phase  II  proposal 
appears  in  a  separate  document. 

Basically,  three  overlapping  efforts  are  foreseen:  (1)  identification,  acquisition 
and  development  of  software  and  computer  hardware;  (2)  exercise  of  the  software 
and  procedures  on  one  or  more  full-scale  finite  element  models,  and  (3)  preparation 
for  full-time  operation  of  the  Air  Force  Aircraft  Model  Center. 


10.1  Software  Identification,  Acquisition,  and  Development 

Section  7  recommended  a  software  solution  tailored  to  the  needs  of  finite  element 
users.  It  also  listed  alternatives  which  appeal  less  favorable.  The  first  task  in 
Phase  II  will  be  to  review  the  alternatives.  Alternative  packages  will  be  tried 
out  on  a  computer,  if  possible,  and  more  detailed  information  on  the  advantages 
and  disadvantages  of  each  will  be  developed,  along  with  hardware  requirements 
and  cost  estimates.  The  approach  recommended  in  Section  7  consists  of  two  com¬ 
mercial  components:  DATATRIEVE  (currently  available  on  the  FDL  VAX),  and 
HISTORIAN  (which  would  have  to  be  procured).  Driver  code  called  FEMREC 
would  have  to  be  written.  This  would  be  a  modest  effort  since  similar  driver  code 
has  already  been  written  by  Mr.  Tenorio  of  ATA.  A  decision  on  whether  to  pursue 
this  approach  or  an  alternative  will  be  reached,  subject  to  review  by  the  Air  Force 
Project  Engineer.  This  decision  should  be  made  within  one  month  after  start  of 
work,  so  that  procurement  of  any  required  software  can  proceed  promptly. 

There  will  be  other  software  needs,  besides  the  basic  database  software,  some 
of  which  can  be  listed  here,  and  some  which  will  become  apparent  as  Phase  II 
proceeds.  First,  CSA  has  some  existing  software  that  'will  be  contributed.  These 
are  ancillary  programs  for  finite  elements,  including  RATS  (element  quality  checks), 
NASTIDY  (renumbering),  and  NASSET  (set  generation).  MSET  (modal  strain 
energy  tabulation)  will  also  be  contributed.  Another  auxiliary  code  that  would  be 
useful  would  read  existing  comments  from  a  bulk  data  deck  and  format  them  for 
insertion  in  the  database.  (See  the  discussion  of  descriptor  files  m  Section  7.) 

Access  to  the  VAX  computers  at  FDL  will  have  to  be  arranged,  along  with 
computer  time  for  running  NASTRAN  on  the  Cyber  or  Cray  mainframes. 

10o2  Work  with  a  Large-scale  Model 

After  the  required  software  has  been  procured  and/or  developed,  and  methods  for 
its  use  established,  it  will  first  be  checked  out  on  a  small  model,  sufficient  to  work 
out  bugs  or  shortcomings  from  the  software.  Soon  thereafter,  work  will  begin  on  an 
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existing  detailed  model  of  an  Air  Force  aircraft.  The  F-15  C/D  model  appears  to 
be  a  good  candidate  for  this  activity,  but  the  actual  choice  will  be  made  with  the 
cooperation  of  the  Air  Force  project  engineer.  In  addition  to  the  model  itself,  we 
will  attempt  to  acquire  as  much  supporting  documentation  as  possible,  especially 
contractor  stress  reports  and  drawings.  The  selected  model  will  first  be  assessed  as 
received  as  to  completeness,  documentation,  reliability,  and  range  of  applicability. 
This  will  involve  a  number  of  NASTRAN  runs. 

After  the  model  has  been  verified,  it  will  be  entered  into  the  database.  This  will 
involve  entering  descriptive  information  as  well  as  the  actual  bulk  data  After  that, 
variations  will  be  generated  and  documented  using  the  database. 

10.3  Preparation  for  Full-Time  Operation  of  the  Center 

The  work  described  in  the  previous  paragraphs  will  provide  a  valuable  end  product 
in  itself.  That  is,  the  F-15  data  and  the  database  software  would  be  available  for  the 
needs  of  FDL  or  other  organizations.  In  addition,  a  major  goal  of  Phase  II  will  be 
preparation  for  subsequent  permanent  operation  of  the  Center.  One  key  to  reaching 
this  goal  will  be  involvement  of  Air  Force  people  in  Phase  II.  This  is  because  the 
Center  is  envisioned  as  a  service  organization,  and  involvement  of  future  customers 
during  Phase  II  will  help  insure  the  success  of  the  Center  after  it  begins  operation. 

Once  the  software  and  procedures  have  become  operational,  it  is  hoped  that 
the  Air  Force  project  engineer  and/or  other  interested  Air  Force  engineers  will 
become  involved  directly  in  exercising  the  software,  generating  variations  of  mod¬ 
els,  recommending  changes  in  procedures,  etc.  Also,  after  the  database  has  been 
populated  with  the  basic  model  and  several  variations,  another  useful  exercise  can 
be  undertaken.  An  Air  Force  engineer  will  be  invited  to  use  the  database  system 
with  minimal  coaching  from  the  contractor.  Besides  examining  the  database  and 
extracting  data,  this  engineer  should  be  encouraged  to  make  modifications  and  new 
entries.  This  will  provide  valuable  feedback  to  the  contractors. 

It  would  also  be  wise  to  solicit  the  attention  of  the  SPO’s  and  other  ASD  orga¬ 
nizations  during  Phase  II.  This  would  be  especially  true  of  ASD/ENFS,  which  has 
already  expressed  interest  in  the  Center. 

10.4  Division  of  Work 

Work  will  be  divided  among  three  sites:  CSA’s  offices  in  Palo  Alto,  CA;  ATA’s  offices 
in  Albuquerque,  NM;  and  the  Flight  Dynamics  Laboratory  (preferably  Building  45) . 
All  three  sites  Eire  equipped  with  VAX  computers  which  can  exchange  data  files  over 
telephone  lines  using  Kermit.  All  three  organizations  have  IBM-compatible  personal 
computers,  in  the  event  that  software  for  these  computers  is  selected. 
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CSA  will  be  the  prime  contractor,  and  will  do  all  the  administrative  work  and 
some  of  the  technical  work  at  its  offices.  The  technical  work  will  include  some 
NASTRAN  runs  on  CSA’s  VAX,  and  some  work  with  the  database  software  and 
the  selected  models.  If  the  HISTORIAN/DATATRIEVE  approach  is  selected,  CSA 
wifi  procure  DATATRIEVE  and  HISTORIAN  for  its  VAX. 

ATA  will  do  initial  software  development  and  integration  at  its  offices.  CSA  will 
exercise  the  software  on  the  ATA  VAX  via  a  telephone  connection.  It  will  then  be 
installed,  on  the  CSA  and  FDL  VAXes  and  exercised  there.  Of  course,  any  necessary 
procurement  would  have  to  be  completed  beforehand. 

Aerospace  Structures,  Inc.,  will  have  primary  responsibility  for  the  work  done 
at  FDL,  and  may  also  do  some  work  off-base.  This  will  include  acquisition  of  the 
selected  model  or  models,  and  supporting  documentation.  Aerospace  Structures  will 
maintain  close  contact  with  Air  Force  personnel  on  technical  matters.  It  is  hoped 
that  these  contacts  will  be  maintained  almost  daily  once  the  software  is  ready  and 
the  models  are  in  hand. 
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This  section  is  a  preliminary  look  ahead  to  permanent  operation  of  the  proposed 
Air  Force  Aircraft  Model  Center.  As  experience  is  gained  in  Phase  II,  these  ideas 
may  of  course  be  greatly  expanded  or  modified. 

This  entire  report  has  emphasized  the  need  for  an  Air  Force  Aircraft  Model 
Center.  To  reiterate,  the  Air  Force  is  not  getting  full  value  for  the  resources  that 
are  expended  on  finite  element  models.  Contractors  should  be  required  to  deliver 
models  to  the  Air  Force.  These  models  (and  others  that  are  available  to  the  Air 
Force)  should  be  documented,  exercised,  verified,  and  publicized  by  the  Center.  The 
Center  would  then  stand  ready  to  provide  Air  Force  organizations  or  contractors 
with  models,  and  could  assist  in  modifying  these  models  as  needed. 

It  should  be  emphasized  that  the  Center  is  not  envisioned  simply  as  a  repository 
or  a  library  function.  The  Center  would  provide  engineering  expertise  and  a  “cor¬ 
porate  memory”  of  the  models  it  stores  that  would  encompass  drawings,  reports, 
and  other  information  in  addition  to  the  computerized  database. 

To  some  degree,  Phase  II  will  be  a  trial  operation  of  the  Center.  A  physical 
presence  on  the  base  is  anticipated,  with  close  cooperation  with  Air  Force  engineers 
on  technical  matters.  While  the  doors  will  not  be  open  for  business  in  the  sense  of  a 
fully  functioning  Center,  it  is  expected  that  Phase  II  will  gain  visibility  and  interest 
among  Air  Force  engineers  so  that  the  Center  could  begin  operations  with  an  initial 
customer  base  in  addition  to  the  necessary  technical  capability.  Presentations  at 
meetings  such  as  ASDP  would  also  help  publicize  the  future  Center. 

A  key  word  in  the  operation  of  the  Center  must  be  service.  The  staff  must 
understand  the  position  of  an  engineer  who  needs  a  finite  element  model  and  is 
under  pressure  from  budget  and  schedule  constraints.  While  the  customer  would 
likely  phrase  his  request  in  specific  terms,  the  Center  engineer  should  solicit  more 
information  about  the  underlying  requirement,  to  be  sure  that  the  customer  is 
asking  the  right  question.  Few  if  any  problems  would  be  solved  by  simple  delivery 
of  a  tape,  with  no  further  interaction. 

Quality  will  be  another  key  to  success.  An  engineer  under  pressure  must  be  able 
to  count  on  the  quality  of  the  data  he  receives  from  the  Center.  This  means  special 
emphasis  on  verification  of  models  and  on  documenting  their  limitations. 

Two  more  key  words  (which  may  seem  to  contradict  each  other)  are  publicity 
and  security.  As  a  service  organization,  the  Center’s  success  will  depend  largely  on 
its  ability  to  publicize  its  existence  and  the  models  it  has  to  offer  among  potential 
customers.  On  the  other  hand,  the  models  that  are  stored  are  valuable,  and  must 
not  be  delivered  to  unauthorized  parties.  One  of  the  most  attractive  features  of 
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the  HISTORIAN/DATATRIEVE  approach  recommended  in  Section  7.  is  the  fact 
that  information  is  stored  in  one  set  of  files  and  the  actual  data  in  another.  This 
makes  it  possible  to  store  the  actual  data  in  a  secure  manner  (off-line,  for  example) 
while  making  the  information  files  freely  available  to  customers  who  wish  to  browse 
through  the  database  contents. 

Mr  Negaard  of  Aerospace  Structures,  Inc.,  and  Dr.  Johnson  of  CSA  axe  both 
former  managers  of  ASIAC.  They  understand  the  operations  of  a  service  organiza¬ 
tion  and  axe  well  qualified  to  guide  the  Air  Force  Aircraft  Model  Center  through  its 
crucial  initial  yeaxs  of  operation. 

As  a  minimum,  the  Center  would  be  staffed  part-time  by  a  senior  engineer  and 
full-time  by  a  junior  engineer  with  good  computer  skills  and  some  finite  element 
background.  A  Micro  VAX  or  equivalent  engineering  workstation  would  probably 
be  required. 
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Appendix  A:  Interview  Transcripts 

This  appendix  presents  interviews  that  were  conducted  with  six  Air  Force  organi¬ 
zations  and  one  NASA  organization.  The  following  organizations  were  surveyed: 
ASD/ENFS  (WPAFB),  Eglin  AFB,  4950th  Test  Wing  (WPAFB),  Wamer-Robbins 
ALC,  Hill  AFB,  Sacramento  ALC  (McClellan  AFB),  and  NASA/Dryden.  One 
transcript  is  provided  for  each  organization,  following  a  standard  format. 

A.l  ASD/ENFS,  WPAFB 

Interviewer:  G.  Negaard  (in  person) 

Persons  interviewed:  Hugh  Griffis,  Robert  Moore 


Organizational  mission: 

Review  contractors’  structural  analysis  including  finite  element  analysis.  Per¬ 
form  hardness  assessments,  look  at  flutter  problems. 

Organizational  capability: 

Personnel:  Two  people  in  the  vulnerability  group,  three  in  the  flutter  group. 
Other  ASD  structures  personnel  are  scattered  among  the  SPO’s. 

Expertise:  Novice  to  intermediate,  able  to  understand  contractors’  work  and 
perform  some  FE  analysis. 

Equipment:  CDC  and  VAX,  Tektronix  terminals;  PATRAN,  NASTRAN. 
They  have  developed  the  DATANET  code  which  uses  FASTGEN,  MOVIE.BYU, 
and  TRACELINKS  to  do  animation  of  large  models.  They  axe  getting 
NAVGRAF  (a  new  package  which  encompasses  graphic  pre-processing, 
COSMIC  NASTRAN,  and  graphic  post-processing).  They  axe  having  a  bal¬ 
listics  and  laser  vulnerability  capability  put  into  ASTROS. 


Organizational  use  of  finite  element  models: 

They  review  contractors’  analysis,  check  some  of  it. 

Use  NASTRAN  and  thermal  codes.  Perform  1-D  thermal  analysis  to  check 
for  exceeding  elastic  limits.  Panel  analysis  for  overpressures. 

Did  T-46  flutter  analysis  using  NASTRAN  to  get  natural  frequencies  and 
modes  shapes,  then  FACES  for  flutter  analysis. 
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Acquisition  methods: 

How  axe  models  obtained? 

Via  S.O.W.  where  possible,  otherwise  by  “begging,  borrowing,  or  steal¬ 
ing”. 

How  are  such  models  verified  and  understood? 

By  contractors  only,  to  any  real  degree. 

How  are  they  archived  and  retrieved? 

Not  really  archived  at  all. 

Lessons  learned  in  this  area? 

Need  a  system  to  obtain  and  keep  models. 

Existing  or  potential  needs  for  FE  models: 

F-15E  model  coming.  Will  be  in  McDonnell-Douglas  format,  will  have  to  be 
converted  to  NASTRAN. 

Have  an  F-15C/D  model  in  McDonnell-Douglas  format,  with  numerous  errors. 
Have  a  need  for  the  dual  role  fighter  model  (F-16E?) 

HALE  (High  Altitude  Long  Endurance)  aircraft  coming  up 

Awareness  of  FE  models  developed  by  contractors: 

GLCM  (Ground-Launched  Cruise  Missile).  Launcher,  truck,  and  trailer. 

B-52  (on  paper  . . .  needs  tying  in) 

KC-135  (on  paper  . . .  needs  tying  in) 

Response  to  the  idea  of  a  model  center: 

They  favor  the  idea,  suggest  that  AFWAL  draft  a  letter  to  each  Program 
Office  asking  them  for  a  model  with  necessary  documentation. 


A. 2  Egiin  AFB 
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How  they  would  like  to  see  a  Model  Center  work: 

They  would  like  someone  to  take  paper  listing  of  models,  put  them  up,  verify, 
and  make  them  available  as  needed. 

There  is  no  real  need  for  quick  response.  A  few  days  or  weeks  is  quick  enough 
for  their  needs. 


Estimate  of  funds  or  time  that  might  be  saved  if  a  Model  Center  existed: 

Paraphrasing:  “When  you  have  to  go  to  the  contractor  for  a  model,  it’s  going 
to  take  a  year  or  more,  so  if  something  has  to  be  done  in  a  timely  manner,  it 
doesn’t  get  done.  Having  a  model  available  would  allow  analysis  of  problems 
that  often  are  not  attempted  due  to  time  constraints.” 

As  for  funds,  the  F-15C/D  model  was  obtained  for  $50,000  from  the  contrac¬ 
tor.  This  procurement  was  tacked  on  to  a  larger  contract.  The  model  was 
actually  “free”;  it  was  the  documentation  that  cost  $50,000.  However,  if  the 
contractor  were  asked  to  create  a  model  it  would  cost  at  least  $500,000. 


A.2  Egiin  AFB 

Interviewer:  G.  Negaard  (telephone) 

Persons  interviewed:  Jim  Robinson,  Wayne  Ingraham 
Phone  number:  AV  88-872-2748/3017 


Organizational  Mission: 

Store  certification  for  aircraft  and  stores. 

Organizational  capability: 

Personnel:  Three  people  in  flutter  analysis,  three  in  loads. 

Expertise:  Mostly  in  flutter.  Loads  people  have  two  entry  level  engineers, 
one  more  experienced  analyst. 

Equipment:  Cyber  176  mainframe,  MSC/NASTRAN  only. 

Organizational  use  of  finite  element  models: 

To  analyze  flutter  with  stores. 
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Acquisition  methods: 

How  are  models  obtained? 

They  have  usually  gone  to  contractors  for  models.  They  do  not  do  any 
modeling  of  their  own.  They  typically  use  stick  models  for  dynamic 
analysis. 

How  are  such  models  verified  and  understood? 

Apply  allowable  loads.  If  wing  torsion  or  wing  bending  exceed  allow¬ 
able  limits  at  any  station,  they  go  back  to  the  contractor  for  additional 
analysis. 

How  are  they  archived  and  retrieved? 

They  have  no  system. 


Existing  or  potential  needs  for  FE  models: 

F-lll  (future) 

A-10,  F-4  flutter  models 

F-15  A/B/C/D  models  (now  on  hand) 

Getting  F-16  model  from  GD  in  a  month  -  primarily  wing,  fuselage  and 
empennage  represented  by  gross  elements.  The  model  will  have  100-200  ele¬ 
ments  for  dynamic  analysis. 


Awareness  of  FE  models  developed  by  contractors: 

F-15  models 
F-16  model 


Response  to  the  idea  of  a  model  center: 
No  response;  not  knowledgeable. 


Estimate  of  funds  or  time  that  might  be  saved  if  a  Model  Center  existed: 
They  had  no  idea  but  felt  they  could  benefit. 


A.3  4950th  Test  Wing 
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A.3  4950th  Test  Wing 

Interviewer:  G.  Negaard  (in  person) 

Persons  interviewed:  Lloyd  Matson,  George  Perley 


Organizational  Mission: 

Design  and  build  modifications  to  existing  aircraft.  They  are  presently  con¬ 
verting  several  old  commercial  707’s  to  C-18’s. 


Organizational  capability: 

Personnel:  Ten  people 

Expertise:  Static,  dynamic,  and  flutter  analysis.  Considerable  expertise, 
ranging  from  a  few  years  to  ten  or  more. 

Equipment:  Cray,  CDC,  and  VAX,  Tektronix  terminals;  PATRAN, 
NASTRAN.  Access  to  MSC/NASTRAN  via  Cybernet.  One  Evans  &  Suther¬ 
land  graphics  system.  They  have  three  VAXes  of  their  own,  and  four  or  five 
Micro  VAXes.  They  are  going  out  for  a  CAD/CAM/  CAE  system  -  Sim, 
Apollo,  or  Intergraph. 


Organizational  use  of  finite  element  models: 

Usually  to  check  static  strength  for  aircraft  modifications  such  as  radomes  or 
equipment  racks.  They  are  also  working  on  a  project  called  ECCM/ARTB 
(Electronic  Countermeasures / Advanced  Radar  Test  Bed)  which  requires  cut¬ 
ting  holes  in  the  top  of  a  C-141  fuselage  to  mount  radomes. 

Acquisition  methods: 

How  are  models  obtained? 

They  often  build  their  own  models  but  sometimes  go  out  on  contract. 
Rockwell,  for  example,  just  made  them  a  model  of  a  450-inch  fuselage 
section  of  a  C-141. 

How  are  such  models  verified  and  understood? 

By  comparing  to  existing  models  or  similar  data.  Also  with  hand  calcula¬ 
tions.  For  example,  the  Rockwell  C-141  fuselage  model  showed  negative 
margins  of  safety  in  several  places,  and  the  original  Lockheed  analysis  did 
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not.  However,  these  points  axe  places  where  the  C-141  has  had  fatigue 
problems,  which  helped  verify  the  Rockwell  model. 

How  are  they  archived  and  retrieved ? 

Cards,  tape,  haxd-copy  printout.  No  system  for  permanent  storage. 

Lessons  learned  in  this  area? 

They  need  a  system  to  catalog  and  keep  track  of  models. 


Existing  or  potential  needs  for  FE  models: 

C-18  (Boeing  707)  fuselage  to  aid  in  fatigue  analysis 

C-135 

C-141 

T-39 

A-37 

A-7D 

Awareness  of  FE  models  developed  by  contractors: 

C-141  done  by  Rockwell 

Response  to  the  idea  of  a  model  center: 

They  favor  the  idea,  if  the  procedure  can  be  quick  and  painless. 


How  they  would  like  to  see  a  Model  Center  work: 

They  would  like  to  be  able  to  pick  up  the  phone,  interrogate  a  database,  pull 
up  a  pictures  of  models,  then  order  the  components  decided  upon. 


Estimate  of  funds  or  time  that  might  be  saved  if  a  Model  Center  existed: 

They  have  no  idea,  because  their  needs  axe  so  special  that  they  generally  have 
to  start  from  scratch  and  build  their  own  models.  (Note:  the  4950th  was 
unaware  of  the  C-141  COSMIC  NASTRAN  model  that  Warner- Robbins  has. 
We  gave  them  a  contact  to  call  there.) 


A. 4  Warner-Robbins  ALC 
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A. 4  Warner-Robbins  ALC 

Interviewer:  G.  Negaard  (telephone) 

Persons  interviewed:  Robert  Wade,  Lt  Randy  Jansen 
Phone  number:  AV  88-468-2525 


Organizational  Mission: 

Depot  maintenance  for  C-141,  C-130,  F-15,  and  H-53  aircraft. 

Organizational  capability: 

Personnel:  Seven  engineers  and  a  manager. 

Expertise:  Mostly  static  analysis. 

Equipment:  Dedicated  VAX-11/785,  Tektronix  terminals, 
MSC/NASTRAN,  Supertab. 

Organizational  use  of  finite  element  models: 

Usually  to  check  static  strength  for  aircraft  modifications  or  repairs.  They 
use  large  models  to  get  internal  loads  which  are  then  used  for  stress  analysis 
on  small  parts.  They  also  look  at  fatigue  problems. 

Acquisition  methods: 

How  are  models  obtained? 

They  usually  build  the  component  models  they  need. 

How  are  such  models  verified  and  understood? 

“As  best  one  can.”  Hand  calculations,  for  example. 

How  are  they  archived  and  retrieved? 

On  tapes  and  on  the  VAX. 

Existing  or  potential  needs  for  FE  models: 

They  have  C-130  and  C-141  COSMIC  NASTRAN  models. 

They  are  getting  an  F-15E  model  in  MacAir  format;  need  to  convert  it  to 
NASTRAN. 
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Awareness  of  FE  models  developed  by  contractors: 
F-15  Models 


Response  to  the  idea  of  a  model  center: 

Not  much  need  for  large  models  except  to  get  loads  for  components.  For  small 
models,  they  go  straight  to  the  drawings,  work  off  the  drawings  as  needed,  or 
take  measurements  from  parts. 

How  they  would  like  to  see  a  Model  Center  work: 

Moderate  interest,  not  sure  how  they  would  benefit. 

Estimate  of  funds  or  time  that  might  be  saved  if  a  Model  Center  existed: 
No  idea. 

A. 5  Hill  AFB  (MMSR,  MMAR,  MMMDR,  MMIR) 

Interviewer:  M.  James  (in  person) 

Persons  interviewed:  Bret  Hamblin,  Tim  Sorensen,  Bruce  Burgon 
Phone  number:  (801)  777-7072 

Organizational  Mission: 

Perform  fatigue  analysis  on  various  parts  of  the  F-4  and  F-16  aircraft.  Hill 
AFB  is  the  central  depository  for  all  aircraft  landing  gear  technology  through¬ 
out  the  Air  Force. 


Organizational  capability: 

Personnel:  MMSR:  8  civilian,  3  military;  MMAR:  10  civilian,  2  military; 
MMMDR:  4  civilian,  1  military 

Expertise:  Novices  in  the  use  of  both  NASTRAN  and  CRACKS  85.  The 
longest  experience  of  any  individual  is  two  years.  Contractors  supply  the 
necessary  expertise,  as  a  rule. 

Equipment:  Two  clustered  VAX-ll/785’s,  Tektronix  4109  and  4129  termi¬ 
nals. 


A.5  Hill  AFB  (MMSR,  MMAR,  MMMDR ,  MMIR) 
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Organizational  use  of  finite  element  models: 

They  develop  finite  element  models  for  fatigue  analysis,  primarily,  but  also 
do  some  design  and  repair  work.  The  models  axe  usually  created  in-house 
with  some  assistance  from  contractors  (BYU  and  General  Dynamics),  or  by 
outright  purchase  (F-16  from  General  Dynamics). 

Acquisition  methods: 

How  are  models  obtained?  . 

Purchased  from  manufacturer  or  created  in-house. 

How  are  such  models  verified  and  understood? 

No  verification  yet! 

How  are  they  archived  and  retrieved? 

Models  are  stored  on  VAX  disks  and  backed  up  on  magnetic  tape. 
Lessons  learned  in  this  area? 

Disk  crashes  have  resulted  in  a  loss  of  time  and  effort.  No  crash  has  been 
bad  enough  to  endanger  the  models  totally  but  a  few  days’  worth  of  work 
was  lost  at  times! 

Existing  or  potential  needs  for  FE  models: 

F-16  and  F-4  aircraft  for  fatigue  analysis.  Hill  AFB  is  the  depository  for  all 
aircraft  landing  gear,  including  models. 

Awareness  of  FE  models  developed  by  contractors: 

MacAir  has  an  F-4  model. 

General  Dynamics  has  a  complete  model  of  the  F-16.  (They  are  rumored  to 
have  an  F-16E  model  as  well.) 

Response  to  the  idea  of  a  model  center: 

They  are  very  receptive.  They  do  express  a  concern  that  the  repository  may 
get  tangled  in  the  typical  government  red  tape,  however.  It  must  be  run  by 
contractors  and  it  must  be  “user-friendly.” 
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How  they  would  like  to  see  a  Model  Center  work: 

A  pictorial  display  of  the  model  using  an  MSC/NASTRAN  database  of 
superelements  of  the  entire  aircraft.  All  models  must  be  completely  verified 
to  be  worth  while! 


Estimate  of  funds  or  time  that  might  be  saved  if  a  Model  Center  existed: 

A  lot  of  money  may  be  saved  by  ensuring  that  all  models  being  used  through¬ 
out  the  Air  Force  axe  keyed  to  the  current  revision  of  the  aircraft.  The  other 
armed  services  should  be  consulted  regarding  models  they  have  so  as  to  reduce 
redundant  efforts  in  model  building  and  -verification. 

A. 6  Sacramento  ALC 

Interviewer:  W.  Gibson  (in  person) 

Persons  interviewed:  Mr.  Sal  Alestra 
Phone  number:  (916)  643-5300 

Organizational  Mission: 

F-lll  and  A-10  aircraft.  Mostly  stress  analysis  with  concentration  on  dura¬ 
bility  and  damage  tolerance  assessments. 

Organizational  capability: 

Personnel:  Five  engineers  and  a  manager. 

Expertise:  Mostly  static  analysis. 

Equipment:  VAX-11/780.  MSC/NASTRAN,  GIFTS. 

Organizational  use  of  finite  element  models: 

They  use  F-lll  and  A-10  models  primarily  for  analysis  of  damage  and  cor¬ 
rosion.  However,  due  to  manpower  problems,  they  are  largely  in  a  reactive 
mode. 

Acquisition  methods: 


How  are  models  obtained? 


A .  7  NASA /Dryden 


All 


They  “found”  three  A-10  models. 

Are  paying  for  two  F-lll  models;  will  procure  six  more. 

Model  deliver  will  be  a  future  contractual  requirement. 

How  axe  such  models  verified  and  understood? 

GD  provides  them  with  GIFTS  steering  files.  They  use  GIFTS  interac¬ 
tive  viewing  commands  to  gain  understanding  of  models. 

How  axe  they  archived  and  retrieved? 

On  the  VAX,  with  backup  tapes. 


Existing  or  potential  needs  for  FE  models: 
They  axe  getting  new  F-lll  models  from  GD. 


Awareness  of  FE  models  developed  by  contractors: 

Strong  awareness  of  F-lll  and  A-10  models  developed  by  GD 


Response  to  the  idea  of  a  model  center: 

They  do  not  favor  the  idea.  They  say  they  are  they  only  Air  Force  organization 
doing  analysis  on  the  F-lll  aircraft.4  Therefore  they  should  be  in  charge  of  all 
F-lll  models.  They  see  requirements  for  them  to  send  models  to  the  Center 
as  an  additional  burden  that  would  detract  from  their  main  mission. 


How  they  would  like  to  see  a  Model  Center  work: 

Use  of  COSMIC  NASTRAN  instead  of  MSC/NASTRAN  would  be  a  “kiss  of 
death”  for  the  Center. 

A. 7  NASA/Dryden 

Interviewer:  M.  James  (telephone) 

Persons  interviewed:  Alan  Carter,  Larry  Shuster 
Phone  Number:  (805)  258-3311  ext  3919 


'‘However,  Wamer-Robbins  personnel  expressed  an  interest  in  an  F-lll  model.  See  Section  A.4. 


A12 


APPENDIX  A.  INTERVIEW  TRANSCRIPTS 


Organizational  Mission: 

Maintain  finite  element  models  of  aircraft  at  NASA/Dryden  and  update  those 
models  when  changes  occur  to  either  the  structure  and  the  stores. 


Organizational  Capability: 

Expertise:  Several  experts  in  the  field  of  structural  analysis  using  codes  such 
as  COSMIC  and  MSC/NASTRAN. 

Equipment:  VAX’s  and  an  ELXI  multiple  processor  system. 


Organizational  use  of  finite  element  models: 

On-site  development  of  finite  element  models  to  be  used  for  stress,  dynamic 
and  loads  analysis.  Most  models  are  made  in-house  but  a  few  have  been 
procured  from  contractors. 


Acquisition  Method: 

How  are  models  obtained? 

Made  in-house  usually. 

How  are  such  models  verified  and  understood? 

In-house  models  axe  verified  as  they  are  made.  The  modeler  must  trust 
the  drawings  and  other  items  used  to  make  models.  The  understand¬ 
ing  of  the  models  is  -very  great  because  the  author  of  the  model  is  at 
NASA/Dryden. 

How  axe  they  archived  and  retrieved? 

The  models  axe  constructed  and  placed  in  storage  on  the  computer  sys¬ 
tem.  Paper  writeups  are  available  to  identify  models. 

Lessons  learned  in  this  area? 

The  models  must  be  backed  up  on  computer  tape  to  ensure  that  they 
are  secure  from  loss.  No  problems  otherwise. 


A .  7  NASA  /Dry  den 
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Existing  or  potential  needs  for  FE  models: 

NASA/Dryden  has  models  of  the  Bl-A  and  the  X29  forward  swept-wing  air¬ 
craft.  They  see  no  need  for  other  models  as  yet  but  as  aircraft  are  added 
to  the  inventory  at  Dryden  they  will  either  acquire  or  build  models  of  those 
aircraft. 

Awareness  of  FE  models  developed  by  contractors: 

NASA/Dryden  has  little  contact  with  outside  contractors  in  the  modeling 
area  except  for  COSMIC  NASTRAN  colloquia.  Rockwell  provided  the  Bl-A 
model  at  Dryden  and  should  have  a  Bl-B  model. 

Response  to  the  idea  of  a  model  center: 

Larry  Shuster  seemed  pleased  to  hear  that  a  finite  element  model  center  is 
being  talked  about.  He  believes  that  the  center  would  be  a  major  step  for¬ 
ward  but  the  problems  associated  with  the  center  could  be  great.  The  major 
problem  will  be  cooperation  from  all  the  organizations  involved. 

How  would  they  like  to  see  a  model  center  work: 

Not  sure  that  they  would  use  the  center  except  to  possibly  contribute  models 
to  the  center! 

Estimate  of  funds  or  time  that  might  be  saved  if  a  Model  Center  existed: 

Would  not  use  center  for  retrieval  of  models  but  may  participate  after  accep¬ 
tance  throughout  the  FEM  community. 
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